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AESTRACT 

In 1974, the Naval Supply Systems Command initiated 
actions to automate the procurement process within the Navv 
Field Contractina System (NFCS). The development project 
was titled. Automation of Procurement and Accounting Data 
Entry (APADE) . By 1979, the original project was discon- 
tinued and a redesign effort was initiated. In an effort to 
determine the underlying reasons for the project's delay and 
problems encountered in developing an Automated Data System 
(ADS) , this thesis examines the APADE project. In addition 
to the reasons and probLems addressed by the Naval Data 
Automation Command's evaluation report, the researcher 
concluded that the procurement procedures utilized by the 
NFCS activities were not defined aor standardized suffi- 
ciently to facilitate ADS development. Additionally, there 
was no indication that this situation was addressed or 
corrected during the planning phase of APADE II development. 
The researcher also concluded that various environmental 
conditions significantly impacted upon the development 
process . 
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I 



r NTRODUCTIDN 



A. NAVAL FIELD CONTR ACTING SYSTEM MISSION 



The Naval Supply Systems Command's (NAVSUP) charter 
specifically assigns them wirh the responsibility for the 
procurement of material and services throughout the 

Department of the Navy except as otherwise delegated by 
higher authority. Included within this procurement 

authority is the management responsibility for the Navy 
Field Contracting System (NFCS) . The NFCS consist of field 
activities, located at various Naval facilities, with dele- 
gated procurement authority of various monetary thresholds. 
It is with the field activities that the ultimate responsi- 



bility of satisfying all the fleet purchase request depends. 

It is the inherent overall mission cf the NFCS to 
provide effective and efficient procurement services -to 
fleet units and Naval Shore activities. This service 
includes supplying locall v -procured standard items, non- 
standard material, and other services. Effective perfor- 
mance cf the procurement function consists of providing the 
customer the material or service requested at tae time it is 
needed and at the best possible price. 



3. BACKGROUND 



Over the last decade. 
Field Contracting System 
response time (the time e 
end-use requisition to del 
service) . During the earl 
Command (NAVSUP) became a 



a major criticism of the Mavv 
has been inadequate procurement 
lapsing from submission of the 



ivery of 
y 1970s, 
ware of 



the needed material or 
the Naval Supply Systems 
several common problems 
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which surfaced during studies conducted on the procurement 
process. They were: 

1. Lack of standardization, 

2. Untimely status Information, 

3. Inflexible management reports, and 

4. Interface only with hard copy documents. 

All of these problems impacted upon the total responsiveness 
of the procurement process and directly affected the mission 
capability of the MFCS. 

In 1974, as a direct result of J -hese studies, NAVSU? 
initiated actions to automate the procurement process at the 
major MFCS activities. These are comprised of the Naval 
Supply Centers (NSC) and Naval Regional Contracting Centers 
(NRCC). NAVSUP envisioned a system that would overcome the 
deficiencies and enhance the response time of the procure- 
ment process. 

The automated system's major objectives would be to: 

1. Automate the procurement document preparation, 

2. Management tracking, 

3. Control of non-standard requisition documents, 

4. Status reports to customers, 

5. Generate management statistics and reports, and 

5. Automate the interface with the accounting functions. 

In April of 1975, a research and development project, APADF 
I (Automation of Procurement and Accounting Data Entry), was 
initiated. Although the RSD effort met with limited sucess, 
it demonstrated a definite need to automate the procurement 
process. 3y 1977, NAVSUP directed that system development, 
APADE II, be initiated with a total system package scheduled 
for completion on April of 1979 . 
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In November 1979, with only partial development and 
implementation at two prototype sites completed, the Chief 
of Naval Operations recommended to NAVSUP that further 
development and implementation be discontinued until the 
Automated Data System (ADS) plan was rewritten and hardware 
requirements analyzed. The new development effort was to be 
accomplished in accordance with the current directives on 
the Navy's Automated Data System Program. 

C. OBJECTIVE 

It is intended that the presentation of this Thesis will 
serve three major objectives. 

First, through the presentation of a documented record 
of the major efforts to automate the procurement process 
within the NFCS, the underlying reasons for the project's 
delay and the problems cited by the Naval Data Automation 
Command's project evaluation report will surface. 

Secondly, and perhaps more importantly, by describing 
the various phases of development of the APADE project and 
comparing them to a recommended ADS development process, 
valuable insight of the prcDlems involved in designing, 
developing, and implementing an automated system will 
promote improved managerial decisions concerning automation. 

The final objective is to contribute an overall benefit 
by presenting a documented historical record of the events 
to facilitate the current automation effort cf the procure- 
ment process. 

D. SCOPE 

The effort to automate the NFCS procurement process has 
covered a minimum of eight years. Over that time period, 
there have been seven commands within the Department of the 
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Navy, four private contractors and the General Service 
Administration (GSA) associated with the project in one form 
or another. It is impossible to record, within a reasonable 
amount of time, all cf the correspondence and documentation 
which transpired during that period. Accordingly, this 

study examines the key documentation and correspondence 
submitted and received by the Fleet Material Support Office 
(FM SO ) , in the role as Central Design Agency for the 
project; the GSA involvement; the role of NA7SU? as the 
project manager; and, finally, the utilization of a private 
contractor to design, develop, and implement the system. 

Additionally, to provide a sound basis from which to 
examine the automation effort, this paper will initially 
focus on two specific areas. The first area to be examined 
will be the role of the NFCS and the procurement process at 
the major activities. The second area will be the evolution 
of the Navy's Automated Data System program and applicable 
regulations in effect during the automation effort. 

E. METHODOLOGY 

The research of the subject was first initiated after a 
telephone conversation with the Executive Officer, Fleet 
Material Support Office (FMSO) Mechancisburg, Pennsylvania on 
23 February 1982 indicated that the researcher's next duty 
assignment would be at FMSO as the APADE project officer. 
The Executive Officer stated that a historical research of 
the APADE effort could provide valuable lessens for future 
managers of the Navy's resources in addition to providing 
the researcher with the required insight to assume the new 
duties. 

Data was collected on three levels; (a) field r°search 
at Naval Supply Center Dakland, FMSD, and Naval Supply 
Systems Command, Washington D.C. ; (b) Discussions and phone 
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conversations with various agency personnel; (c) research as 
indicated in the list of references. 

F. THESIS ORGANIZATION 

The format described in the table of contents was chosen 
because it seems to present the material in a logical 
sequence. Chapter One is the introduction and consists of a 
brief discussion of the automation effort with the scope and 
objective of the research effort. The methodology of 
collecting the data is also provide! . The next chapter is 

devoted to the discussion of the role of the NFCS within the 
NAV SUP organization. A detailed explanation of the procure- 
ment process and the problems encountered are also 
presented. Chapter Three provides the reader with insight 
of the Navy's ADP Program, its objectives and the laws and 
regulations that control it. The fourth chapter is a 
detailed analysis of the automation effort as examined from 
various correspondence, files, publications and interviews. 
Chapter Five discusses the NAVDAC evaluation and constraints 
placed on the project by the CN3. Chapter Six contains the 
researcher's conclusions. 
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II 



. NAVY FIELD CONTRACTING SYS TEM 

As mentioned in the introduction, to facilitate the 
examination of the effort to automate the procurement 
process within the Navy Field Contracting System (NFCS) , it 
is essential to first focus on the organizational 
characteristics and functional requirements of the system. 

A. BACKGROUND 

The Navy Field Contracting System, under the cognizance 
of the Naval Supply Systems Command (NAVSUP), consists of 
all contracting offices of Naval activities except the 
f ol lo wing: 

1. Automatic Data Processing Selection Office, 

2. Office of Naval Research its Branch Offices and its 
Resident Representatives, 

3. Military Sealift Command and its field activities, 

4. Marine Corps and its field activities; however, its 
air stations are a part of the NFCS, 

5. Headquarters, Naval Air Systems Command, its Naval 
Plant Representatives Offices and its Naval Aviation 
Logistic Center, Commercial Rework Department, 

5. Headquarters, Naval Sea System Command, its Naval 
Plant Representative Offices and its Supervisor of 
Shipbuilding, Conversion and Repair, 

7. Headquarters, Naval Electronic System Command, and 

3. Headquarters, Naval Facilities Engineering Command and 
its field activities [Ref. 1: p . 1-40 1 . 5 1b ] . 

In i otal, the NFCS is comprised of several hundred indivi- 
dual activities, each having a limit to their purchasing 
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authority as perscribed by the Naval Supply Systems 
Command (NAVSUP) . 

Centralized control is provided by the establishment of 
nine geographical procurement regions throughout the world. 
Six of the regions are located within the Continental U.S. 
with the remaining three being Hawaii, Far East, and Europe. 
Each region has a Naval Supply Center (NSC), Naval Supply 
Depot (NSD) , or Naval Regional Contracting Center (NRCC) , 
formerly known as Naval Regional Contracting Office (NRCO) , 
designated as the cognizant contracting office for that 
region. It is within this organizational framework that 
NAVSUP centralizes the buying by region, area, or commodity 
to the maximum extent possible. 

3. CATEGORIES OF PURCHASING ACTIVITIES 

NAVSUP categorizes purchasing activities by defining 
them by the type of authority and responsibility they have 
with respect to purchasing. The three categories are: (1) 

central buying, (2) ncncentral buying, and (3) limited 
buying. 

1 . Cen t ral 3uv in g 

Th9T9 a. r 9 t. hr 9 9 iiffsrsnt levels of c9Qfr9li'Z9d 
buying. The first level is regional buying. The acrivites 
designa~ed for regional buying are the NSC’s and NRCC’s. 
They are responsible for buying items assigned by NAVSUP and 
for making purchases which exceed L ha limited purchase 
authority of the activities within their jurisdiction. In 
addition, for activities designated as the regional 
contracting office for their region, the responsibility o^ 
assisting NAVSUP in meeting the functional and nonfunctional 
management reguiremer. ts is assigned. This includes, but is 
not limited to: 
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1. Providing guidance aid technical assistance, 

2. Evaluating staffing, performance, and effectiveness of 
NFCS contracting offices, 

3. Determining compliance with applicable priorities of 
law and regulations, and 

4. Assigning contracting officer authority for NFCS 
activities and personnel. 

The second level of centralized buying is area 
buying. These are Navy field activities, desianated by 
NAVSUP, responsible for purchases which are in excess of the 
contracting authority granted to other Naval activities 
located within a particluar area. Currently, there are 
seven area buying activities located within the Cont inertial 
U.S. They are: 

1. Naval Air Station, Jacksonville, Fla., 

2. Naval Air Station, Pensacola, Fla., 

3. Naval Air Station, Corpus Christi, Tx., 

4. Naval Shipyard, Portsmouth, H.N., 

5. Naval Supply Center, Puget Sound, Wa . , 

5. Naval Supply Center, San Diego, Ca. , and 

7. Supply Department, Naval Administrative Command, Naval 
Training Center, Sreat Lakes, 111. 

Additionally, the area buvina activities will make purchases 
which are within the authority of the activities they 
service when it is advantageous due to complexity of the 
purchase or their additional capabilities are required. 

The third level of centralized buying is commodity. 
This level of buying is only performed by ■‘■he NAVSUP managed 
inventory control points (I C? 1 s) . Purchasing by ICP’s is 

usually for new stock requirements and system stock replen- 
ishment for support cf major systems throught the Navy. The 
activities designated as inventory contol points are: 
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1. Navy Aviation Supply Office, 

2. Navy Ships Parts Control Center, and 

3. Navy Resale and Service Support Center. 

2 . Ncncentral Buying 

In general, activities designated as noncentral 
buying activities are responsible for buying supplies and 
services in support of their assigned mission as well as for 
local use. Purchases are a ads within the monetary limits as 
imposed by NAVSUP. Examples of noncentral buying activities 
are: Naval Shipyards, Naval Air Development Centers, Naval 

Weapons Centers, ana Naval Construction 3atta liens. The 
imposed ourchase limitation is usually $100,300 with the 
exception of Naval Shipyards engaged in the Naval Nuclear 
Propulsion Program. They have unlimited purchase authority 
within their mission area. 

3 • liSlih ed B uy ing 

Limited buying activities are those designated in 
writing by NAVSUP assigning purchase authority and types of 
purchases allowed. Examples of these activities are 
Commissary Stores, Naval Reserve Office Training Corps, and 
Naval Health Sciences Education and Training Command. 

C. PROCUREMENT PROCESS 

For the purpose of analyzing the procurement process 
within the NFCS, attention will be focused on the regional 
buying activities (NSC and NRCC) . The reason for analyzing 
the procurement process at the NSC and NRCC is two-fold. 
First, the majority of the automation effort has concen- 
trated on analyzing the procurement process at the regional 
buying activities due to the large volume in procurement 
actions. Secondly, it provides a better understanding of 
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the magnitude and scope of the overall procurement process 
in the NFCS by examining the organization and functions of 
these two activities. 



1 . NSC and NRCC Organization 



although the NSC’s and NRCO's are responsible for 
performing the same procurement mission and governed by the 
same purchase regulations, there is a significant difference 
in their organizational composition to accomplish that 
mission. The NSC procurement component functions as a 
department within that activity as contrasted to the autono- 
mous NRCC. These relationships are exhibited by Figures 2.1 
and 2.2. 



a. NSC Purchase Department 

The purchase department in the standard NSC is 
comprised of three separate divisions which share the 
overall responsibility to plan and conduct purchase and 
contract administration operations for the activity. The 
following is a brief discussion of those divisions’ respon- 
sibilities within the organization. 



3uying and Order Division 

The Buying and Order Division is responsible 

for : 

1. Reviewing purchase request, 

2. Determining types and methods of purchase, 

3. Reviewing qualifications of contractors, 

4. Performing bid analysis, 

5. Performing negotiations with contractors, and 

6. Placing orders under established federal contracts. 
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Figure 2.1 Standard Or gan izattions for NSC and Depots 
(NAVSOP Man. Vol.I) 

Purchase Service Division 

The Purchase Service Division is responsible for 
preparing and issuing all invitations for bids and request 
for proposals as directed by the buying and order division. 
In addition, they maintain records of bids received, assign 
purchase request to cognizant buyers, prepare and issue all 
contractual documents, maintain control records, and prepare 
statistical procurement reports. 
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Figure 2.2 Standard Organization for NRCCs (NAVSOP Man. 
Vol.I) 



Contract Administration Division 

This division is responsible for administration 
of the contract once it is awarded. They issue change 
orders and obtain written acceptance of contractors to 
amendments and modi ficat i ons. Additional responsibility 
inclu des : 
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1. Amend, modify, and terminate contracts due to default; 

2. Collect, assemble, analyze, and promulgate contractor 
performance data; and 

3. In cases of delinquent deliveries, effect contractor 
discipline. 

b. NRCC Purchase Organization 

As previously mentioned, the NRCC’s carry out 
their assigned mission as a completely autonomous organiza- 
tion. However, like the NSC’s, they have three divisions 

that share in the responsibilities of that mission. 

Field Management Division 

This division provides the purchase management 
guidance, assistance, and advise to the NFCS activities 

within their cognizant regional areas as delegated by 
NAVSDP. The general duties of the division are comprised of 
♦he following: 

1. Appraise organization and staffing, 

2. Evaluate levels of contracting authority, 

3. Administer and coordinate purchasing training 

programs, 

4. Prescribe standard operating procedures, 

5. Advance planning, 

6. Analyze purchase statistics, trends, workloads for 
management effectiveness, and 

7. Determine the need for indefinite delivery type 
contracts for common type items. 

Administrative and Planning Division 

The administrative aid planning division 

performs administrative, planning, personnel, office 

service, and purchase support services such as: 
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1. Analyzing internal operating methods, 

2. Administering various management improvement programs, 

3. Estimating budget and personnel ceiling requirements, 

4. Preparing and maintaining administrative directives, 

5. Providing mail, filing, and duplicating services, 

6. Screening, recording, and routing all incoming 
purchase request, 

7. Preparing and mailing invitation for bids (IF3) and 

request for proposals (3FP) , 

8. Maintaining contract files, and 

9. Preparing external statistics and procurement reports 
for the activity. 

Purchase Division 

The purchase division of the NRCC plans and 
conducts the purchase and contract administration functions 
for the activity. That responsibility includes the 
folio wing: 

1. Reviews purchase request for correctness, 

2. Analyzes and evaluate bids and proposals, 

3. Directs the issuance of IF3S and RFPs, 

4. Conducts contract negotiations, 

5. Participates in pre-award surveys, 

6. Determines contractor responsibility, capacity, and 
performance status, 

7. Determines when to award, amendment, claim, and termi- 
nate contracts, and 

8. Performs contract administration functions. 

2. NSC and NRCC Procurement Process 

Basically, the overall procurement missions of the 
NSC's and NRCC's are identical. They are both responsible 
for satisfying the purchase requirements of the fleet as 
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well as all purchase requirements exceeding the limited 
purchase authority of other Navy shore activities within 
their cognizant geographical region. They have both been 
granted unlimited purchase authority by NAVSUP. The infor- 
mation requirements, regulations, functions, and procedures 
of the NSCs and NRCCs to carry out these responsibilities 
are governed by the Defense Acquisition Regulations (DAR) , 
Navy Contracting Directives, the NAVSUP Field Purchasina 
Manual {NAVSUP P-467) , NAVSUP policy guidance, and locally- 
developed instructions. 

Although the NSC’s and NRCC' s are organizationally 
different, the basic procurement functions of these activi- 
ties are sufficiently similar to be described by one gener- 
alized information flow. This is graphically displayed by 
Figure 2.3. 

Processing starts with the receipt of a purchase 
request at the procurement office. Requisitions are usually 
received in the form of a hard-copy document or punched 
card. Specifications, drawings, and other supporting docu- 
mentation will be provided as required. A control desk is 
usually established to manually log-in each document by 
requisition number, date received, dollar value, and 
description. The requisitions are then sorted according to 
a customer assigned priority number. They are screened for 
completeness, consolidated when appropriate, assigned a 
Control Number, and placed in folders. The control desk 
determines the commodity and assigns the appropriate buyer 
or organizational code depending or. local criteria. The 
buyer receives the requisition and reviews if for complet- 
ness and accuracy. 

At this point, the next procedure depends on the 
estimated value of the procurement action. For small 
purchases, under 310,000 (Changed to 325,000 in April 1982), 
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the buyer will issue a Request For Quote (RFQ) or obtain an 
oral quotation since the regulations allow him/her to 
perform the procurement by negotiation vice formal adver- 
tisement. However, for procurements exceeding the $10,000 
($25,000) threshold, the buyer must either issue a formal 
Invitation For Bid ( IFB) or obtain approval from a higher 
level to negotiate the procurement. After determining the 
method of procurement, IFB or negotiation, the process is 
basically the same. 

After the buyer receives the offers from prospective 
contractors, those offers are evaluated and contracts are 
awarded or order placed with the successful vendor. The 
contract documents are signed, distributed, and filed for 
use by personnel administrating the contract until all 
action is completed and the vendors invoice is paid. 
Additionally, regulations require that these files be kept, 
for a period of seven years . 

It should be understood at this point that this 
discription has been highly simplified to enhance the read- 
er's understanding. The regulatory requirements and the 
procedural details dealing with contract preparation, evalu- 
ation, negotiation, and solicitation in conjunction with 
contract administration can only be fully appreciated by an 
indepth study of the laws and regulations of government 
procurement. Since this examination is concerned with the 
automation of the procurement process, an indepth study of 
this magnitude is considered beyond the scope of the 
research. However, a list of the required input, output, 
and report documentation should provide the reader with an 
appreciation of the scope of the procurement process. 
Appendix A provides a list of the major input, output and, 
report documents required by these two Navy activities. 
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PROBLEM AREAS 



In the early 1970s, several stadias of the government 
procurement process were initiated. This mainly stemmed 
from the 1972 Report to Congress from the Commission on 
Government Procurement. 3ecause of the increased emphasis 
placed on government procurement, the Navy began to perform 
evaluations at its procurement activities in order to 
surface and correct potential problem areas. 

One of the first problems identified at the NSC's and 
NRCC's was inefficiency due to highly labor-intensive 
procurement actions with relatively little data processing 
support. All document preparation and file maintenance was 
done manually. The data processing support received by the 
NSC purchase function was provided Dy a different oraaniza- 
tional component of the Supply Center. This required the 
sharing of large-scale equipment which supported a wide 
range of functions. Although the NRCC's had more control of 
their data processing resources, they were limited in size 
and capacity [Ref. 2: p.4.1-2]. 

A second problem identified was the lack of standardized 
procedures. Although both activities are governed by the 
same laws and regulations, the manner in which they inter- 
preted the regulations and methods employed in enforcing the 
regulations varied considerably. A major reason for this 
was the different types of supplies and services procured by 
each activity. Another problem identified was the untimely 
flow of information on the status of the procurement 
actions. Customer queries for status are handled by the 
buyers who must divert their time from the buying action to 
perform mundane document searches. This resulted in 

searches being performed whenever the buyer could "get to 
it" [Ref. 2: p. 4.1-3]. 
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The inability of the current procurement system to 
interface effectively with the other DOD and Navy financial, 
supply, and contract administration systems surfaced as 
another major weakness. The majority of interfacing was 

through copies of contract documents and other non-machine- 
processafcle media. This usually resulted in additional 
errors and sometimes the non-reconciliation of financial 
accounts and untimely information. 

Other problems identified were delays in the preparation 
of formal procurement documents and manual entry of procure- 
ment data with a high incidence of duplication. 

As these problem areas were identified, NA7SUP began to 
understand why the effectiveness of the NFCS was dimin- 
ishing. Collectively, the probLems created excessive 

response time in the processing of procurement actions. 
This lead to a reduction in mission performance and customer 
dissatisfaction. NAVSUP, in 1974, initiated action to auto- 
mate the procurement process in an attempt to find a solu- 
tion to their problems. dowever, they first had to rely on 
the Navy’s ADP Program. 
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III. NAVIES AUTOMATED DATA PROCESSING PROGRAM 
A. BACKGROUND 

As John Mauchly and J. ?. Eckert constructed the first 
all -electronic computer, ENIAC, in 1945, little could they 
have realized the total proliferation of computers within 
the federal government thirty years hence. The first compu- 
ters installed in the government were mainly used to support 
research projects within DOD. The first general purpose or 
business use of a computer was by the Bureau of Census to 
compile the 1950 census data. By 1965, the number of 
general purpose computers utilized by the federal government 
increased to 2,412 with a data processing price tag over 
$1,132 billion. This significant increase in volume was 
mainly attributable to the employment of general purpose 
computers in the fields of material, financial, and adminis- 
trative management. By 1977, there were over 11,000 general 
purpose computer systems in operation within the government 
[Ref. 3: p.1]. 

1 . U. S. Navy 

A major user of computer technology within DOD is 
the Department of the Navy (DON) . From 1959 to 1975, DON 
had spent more than 2.3 billion dollars for Automatic Data 
Processing Equipment (ADP 3 ) and had acquired over 1100 
general purpose computer systems to perform logistic and 
administrative functions. As of April 1932, DON had a total 
of 2728 systems and approximately 14,634 personnel associ- 
ated with the operation and maintenance of those syst«ms. 
The DON 1983 fiscal year budget included 1.035 billion 
dollars for the acquisition and maintenance of ADP systems 
[Ref. 4]. 
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Forecasting the future demand on computer systems, 
the DON established, in 1959, an Automatic Data Processing 
Program to control the valuable data processing resources. 
The program was and is today a compilation of Navy policies, 
objectives, plans, procedures, and principles for managing 
ADP resources. The program is further intended to enhance 
the Navy capabilities in the computer field. It provides 
general guidance to Navy components for technical advance- 
ment and effective, efficient, and economical use of 
computer equipment and techniques [Bef. 5: p.1]. 

The program’s general guidance presents principles 
for long range development of the Navy’s data processino 
capabilities as well as exploitation of computer technology, 
telecommun ications, and management science techniques. The 
program is headed by the Deputy UQder Secretary of the Navy 
(Financial Management) who is designated the Senior Policy 
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1. The combining of the automated management information 
systems to form an aggregated system termed, M a 
Department of rhe Navy management information system," 

2. The systematic evolution and amplication of automatic 
data processing equipment and associated techniques in 
improving information flow -o and from management with 
optimal uniformity, c ompa tabiii ty , and responsiveness. 
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3. The development and exploitation cf automatic data 
processing equipment and related advanced scientific 
techniques, and 

4. The orderly development of standardization to improve 
information interchange [Ref. 5: p.2]. 

Included in the general plan were the policies, 
principles, concepts, and procedures to be followed to 
ensure proper implementation of program objectives by the 
various Navy organizations. It provided major stages of 
system development and detailed instructions for conducting 
planning and feasibility studies. Further guidance was 
provided concerning the policy of system design, acquisi- 
tion, installation, and conversion of ADP systems. In addi- 
tion, •‘■he plan outlined general principles dealing with the 
need for: 

1. Preparing economic analysis v o determine benefits of 
automation and its impact on direct and indirect, cost, 

2. Exploiting the full capabilities of available equip- 
ment and the management sciences, 

3. Automating applications which have a legitimate 
history and purpose with consistency and prudent 
speed, and 

4. Continuously anticipating and implementing reorganiza- 
tion [Ref. 5: p.2]. 

By 1965, the growth in computer technology and 
widespread use of computers by the government began to 
create new problems, many relating to the rapid technolo- 
gical changes in the ADP field. In an attempt to deal with 
these problems and "fix responsibilities within the govern- 
ment for coordinating purchase, lease, maintenance, opera- 
tion, and utilization of ADP5 by federal departments and 
agencies". Congress passed Public Law 99-306, commonly known 
as the Brooks Bill, on October 31, 1965. 
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After the passage of the Brooks 3111, SECNAV reaf- 
firmed the objectives of the Navy's ADP program through the 
issuance of SECNAV Instruction 10462. 7B in March of 1966. 
This instruction reiterated the general concepts, purpose, 
and principles previously addressed in 1959. 

By 1970, DOD began to stress improved management of 
the use of ADP resources by the various Military 
Departments. Because of this newly kindled interest by DOD, 
DON modified their ADP program. They began to emphasize 
better planning, costing, and control of system development. 
At the same time, the major program objectives became more 
generalized stating the need for the exploitation and cost- 
effective use of automated data processing in addition to 
effecient acguisition and management of its resources 
[Ref. 5: p-2 ] . 

As more attention was focused on the utilization of 
ADP resources, the rules and regulations that governed those 
resources began to multiply. 



B. LAWS AND REGULATIONS 



1. A Federal Law 



Public Law 89-306 (Brooks 3ill) was the first 
substantial attempt to provide legal guidance to the govern- 
ment for the economic and efficient utilization of ADP 
resources. The bill stipulated that administrative responsi- 
bility would be divided among three separate agencies. The 
General Services Administration (GSA) in a major role, was 
given authority to acquire, operate, fund, and dispose of 
ADP items addressed in the legislation. Additionally, GSA 

was directed to act as the "day- to-day" manager of all ADP 
resource acquisitions [Ref. 6: p-2], The Office of 

Management and Budget (OMB) was given a supervisory role. 
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directed toward providing guidance to the federal agencies 
cn issues of policy. They were also tasked with the respon- 
sibility of resolving any disputes arising under the bill. 
The Department of Commerce was charged with providing any 
technical and scientific advisory service relating to ADP 
systems. 

The bill provided specific guidance to GSA ir. 
executing •‘•heir responsibilities. They were: 



1 . 


GSA 

(Sec 


is given sole procurement authority 
tion 1 1 1 (e) ) . 


for 


ADPE 


2. 


GSA 


is permitted to delegate its procurement 


authority 




to 


an agency, either on a case-by-case 


bas is 


or 



blanket delegation (Section 111(b) 2). 

3. GSA is to provide regulations for reutilizaticn of 
ADPS within the government (Section 111(b) 11). 

4. The bill is applicable no all federal agencies and not 
the private sector (Section 111(a)). 

5. GSA will control an ADP revolving fund available to 
agencies without fiscal year limitations but reimbur- 
sable to GSA (Section 111(c)). 

S. GSA is prohibited from interfering in an agency's use 
of ADPS or in agency's determination of i*s require- 
ments (Section 111 (g) ) . 

After the enactment of the Brcoks Bill, various 

federal agencies began to formulate and issue guidance 
concerning ADP resources within their control. 

2. OMB Circular A- 71 

OMB, performing their supervisory function, issued 
Circular A - 7 1 . First, the circular directed that OMB be 
responsible for the overall leadership and coordination of 
ADP system management. Secondly, the circular tasked GSA 
to: 
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. Provide Federal Supply Schedules for use by agencies 
in ordering ADPE. 

2. Provide technical information to users on the capabil- 
ities and performance of ADPE. 

3. Ensure the efficient utilization of ADPE. 

4. Attempt to standardize purchase procedures whenever 
possible. 

Finally, the circular taslced the heads of the various agen- 
cies with the responsibility for: 



1. Aqency-wide planning, coordination, and control of 
equipment utilization. 

2. Determining ADPE requirements. 

3. Cost-effective utilization of AD? systems by 
exploiting or merging of systems across organizational 
lines. 



3. GS A Guidelines 



Under the authority granted by P.L. 89-306 and OMB 
Circular A-71, GSA issued specif is guidance dealing with 
acquisition and management of ADP resources to all federal 
agencies. The two primary regulations used as vehicles to 
implement rh is guidance were the Federal Procurement 

Regulation (FPR Section 1-4.) and the Federal Property 
Management Regulation (FPMP Section 101-35 thru 101-36). 

Since the provisions of these regulations are appli- 
cable to DOD, their significance to the management of the 
Navy's ADP program becomes apparent. 



a. Federal Procurement Regulation 

Section 1-4 of •‘■he FPR is totally dedicated to 
the acquisition of ADPE, software, maintenance, service, and 
supplies. ADPE is defined by the FPR as "general purpose 
commercially available, mass produced automated data 
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processing components. *' However, FPMR defines it as 
"general or special purpose," which exhibits just one of 
several inconsistencies found in GSA guidance. 

Two subparts within section 1-4 of the FPR, 
.1103- General Policies and 1104- Procurement Authority, 
require additional explanation due to their relevance with 
the subject of this research. Section 1-4.1103 sets forth 
the general policies for obtaining GSA approval prior to the 
acquisition of any ADPE. An agency may only procure ADP5 
when a sDecific delegation of procurement authority (DPA) 
has been granted by GSA. However, ADPE may be acquired 
without GSA approval provided that: 

1. The ADPE is specifically designed for a specific 
application. However, ADPE on the commercial market 
cannot be acquired under this exception unless it is 
modified to such an extent as to preclude future use 
of the equipment for o^her purpose. 

2. Acquisition is through a GSA requirements contract. 

3. The acquisition cost does not exceed $50,000 [Ref. 7: 
p. 10:1-4, 1103-1]. 

On September 8, 1978, this section of th<= FPR 

was modified by Temporary Regulation 46, "Use of Small 
Purchase Procedures and Schedule Zontracts for Automatic 
Data Processing (ADP) Requirements'* * Ref . 6: p. A-3]. Items 
(1) and (2) were not changed by the modification; however, 
agencies are now permitted to acquire ADPE without prior GSA 
approval in the following additional instances: 

1. If placing an order against a GSA schedule contract 
given that: 

(a) The order is within the terms and conditions 
of the contract, 

(b) The order is within the maximum order limitations 
of the contract, and 
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(c) The total purchase price does not exceed 

.3 300,000. 

. The total value of the procurement does not exceed 
3300,000 for competitive procurements and $50,000 for 
procurements from a single source. 

Section 1-4.1104 specifies the procedures for 
requesting GSA approval if the proposed procurement does not 
fit the above exceptions. The agency must submit the 
following information: 

1. Copies of the proposed solicitation document, 

2. Estimated dollar value of the procurement, 

3. Estimated system life, 

4. Location of the data processing facilities involved, 

5. The fiscal quarter during which the solicitation is 
expected to be released, 

5. A listing of any unique support requirements, 

7. A statement that an evaluation has been made to ensure 
that the the proposed procurement represents the 
lowest overall cost alternative to meet the need, 

8. Evidence whether or not site construction is required, 

9. A statement that the need to document ADPS has been 
documented, 

10. Statement that all available resources have been 
screened and none are available to meet the agency’s 
need, and 

11. A thorough and compLete justification, if applicable, 
of the requirement for a sole source acquisition 

[Ref. 7: p. 1-4.1104]. 

GSA has three options in dealing with an agency 
procurement request (APR) . First, they can delegate the 
authority to procure the ADPE to the requesting agency. 
This is what was refers! to above as a delegation of 
procurement authority (DPA). Secondly, they can issue a 
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DPA, but require that GSA maintains some type of involvement 
in the acquisition. Finally, GSA can conduct the acquisi- 
tion themselves. Irrespective of GSA*s option, action must 
be initiated within twenty working days or the requesting 
agency may assume that a DPA has been granted. 

b. Federal Property Management Regulation 

Sections 101.35 and 101.36 provide the proce- 
dures pursuant to GSA's function as the "dav-to-day" manager 
of all federal AD? acquisitions. The regulation discusses 
such matters as leasing equipment, reutilization of excess 
ADP 2, Federal Software Exchange Program, and the ADP 
revolving fund. Additionally, the regulation requires that 
each APR for systems estimated at over $100,000 be accompa- 
nied with a well documented system study. This study should 
demonstrate that: 

1. The functions to be performed are essential and 
readily adaptable to automation, 

2. An effort was made to reduce the workload of the 
activity before proceeding with an expansion of 
capacity, 

3. An interim upgrade, software modification, or schedule 
changes cannot be accomplished to improve perfor- 
mance , and 

4. The new system design will achieve the highest 
possible effectiveness [Ref. 8: p. 19]. 

Although GSA issues a multitude of directives 
dealing with ADP resources, there are two additional docu- 
ments that should be mentioned. First, the Federal 
Management Circular provides general ADP policies to 
federal agencies, but supplies no specific procedures. 
Secondly, GSA issues Temporary Regulations which provide 
interim changes to the F?R and FPMR [Ref. 6: p. A-3 ]. 
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It is within the framework of the regulations 
previously discussed that DOD and DON must conduct the 
acguisition and management of ADP resources. In this 

regard, DOD and DON have issued a myriad of instructions and 
directives to provide further guidance in the effective and 
efficient management and acquisition of ADP resources. 

4 . DOD G uide lines 

Upon reviewing the numerous guidance promulgated by 
DOD, it is apparent that two instructions are extremely 
significant within the scope cf this research. These 
instructions deal with the acquisition and management of AD? 
resources. 

a. DOD Instruction 5100.43 

DOD Instruction 5100.40 entitled 

"Responsibilities for the Administration of the Automatic 
Data Processing Program", was issued in 1970. This instruc- 
tion designated the Assistant Secretary of Defense 
(Comptroller) as the administrator of the DOD ADP program. 
His responsibilities include developing program policies, 
criteria, and standardization of ADP resources throughout 
the Defense Departments. The Service Secretaries were 
required to designate a Senior AD? Policy Offical (SPO) . 
The SPO was responsible to evaluate ADP systems before 
implementation in hopes of promoting effective selection, 
acguisition, and reutilization of ADPS. 

b. DOD Directive 4 105.55 

DOD Directive 4105.55 (dated Say 19, 1972) enti- 

tled "Selection and Acquisition of Automatic Data Processing 
Resources", established policies and guidance for the selec- 
tion and acquisition of ADPE, computer programs, ADP 
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contractual services, and supplies. The directive stipulated 
that the decision to acquire ADP resources will be contin- 
gent on a well documented study, demonstrating that: 

1. A valid information requirement exist. 

2. The function or process to be performed is essential. 

3. Use of ADP resources is the most cost-effective method 
for the performance of the function. 

4. The ADP system will be designei to provide the highest 
practicable degree of effectiveness and operational 
economy. 

5. The lowest overall cost alternative satisfying the 
requirement is determined prior to + he selection and 
acquisition of ADP re sources. 

Prior to acquiring any replacement ADPE, consid- 
eration of automated data system design or redesign is 
required. This enables the services to exploit the existing 
capabilities of ADPE. Use of commercial sources for selec- 
tion and acquisition of ADP resources is not permitted 
unless sharing or reutilizing existing government ADP 
resources is uneconomical or unsatisfactory. The directive 
further requires that development of system specifications 
and requirements must be independent of a particular 
vendor's product to avoid unfair acquisition practices. 

Selection of \DPE for multiple installations is 
initiated when the system to be used is centrally designed, 
programmed, and maintained for installations concerned. The 
directive states that in this case, a prototype installation 
will be selected for initial system implementation. The 
remaining sites will not receive the system until the proto- 
type system has adequately performed in its operational 
environment and has been reviewed and certified through 
established evaluation criteria. 
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In an effort to promote effective selection and 
acquisition of ADP resources, the directive required that 
each military department establish a professionally staffed 
activity. The activity would be tasked with developing 
solicitation documents, evaluating vendor proposals, and 
performing competitive selection of ADPE exceeding an esti- 
mated value of 5200,000 if the equipment was leased and 
$500,000 if purchased. Acquisition of ADPE estimated at a 
lower value would be administered by the requesting 
activity. Additionally, the directive specified that 
service secretaries were responsible for approving the 
selection of ADP resources. This authority could be dele- 
gated only on acquisitions estimated below 5500,000. 

5 ♦ Mil Gu id el in es 

Desiring to provide internal guidelines for review, 
approval, and procurement of ADP resources, the Assistant 
Secretary of the Navy for Financial Management (SPO,AD?) 
sponsored several instructions. Today, guidelines have been 
promulgated for such things as data element and code stand- 
ardization, programming language standardization, ADP 
sharing, ADP equipment reutilization, and the management of 
automated data systems development just to name a few. Th=- 
NA7DAC (Naval Data Automation Command) Instruction 5230.2 
lists over 40 SECNA7 (Secretary of the Navy) Instructions 
for AD? resource management. 

Perhaps the most important instruction that influ- 
enced and guided the procedure used to automate the procure- 
ment process of the NFCS was SECNA7INST 5236. 1A entitled 
"Specification, Selection, and Acquisition of Automatic Data 
Processing Equipment (ADPE)", dated 30 April 1974. Th e 
instruction was the Navy’s product of implementing the ADP 
directives provided by 0M3, GS A, and DOD. The instruction 
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also delineated the responsibilities of the DIR DON ADPM, 
OP-942, and the Automatic Data Processing Equipment 
Selection Office (ADPESO) . 

The DIR DON ADPM was directly responsible to the SPO 
for developing and promulgating plans, policies, and proce- 
dures with respect to AD? review and evaluations. He was 
also designated as the Source Selection Authority. 

ADPESO, later designated ADPSO, was established as a 
direct result of DODINST. 4105.55 requiring the formation of 
a professionally staffed activity within each service. 
Initially, ADPESO was responsible for acquisition of only 
ADPE, but eventually they assumed responsibility for soft- 
ware, services, and supplies. They were also tasked with 
functioning as the primary DON liaison office for ADPE 
acquisition matters. 

The instruction reaffirmed the original program 
policy of conducting studies prior to the acquisition of ADP 
resources. It emphasized that developing data processing 
systems and/or acquiring computer equipment must be preceded 
by studies which form the basis for (1) identifying informa- 
tion requirements, (2) determining the kind of system 
needed, and (3) developing specifications to select and 
acquire computer equipment. 

The approval authority and associated monetary 
thresholds were also established by this instruction. The 
levels of approval required was based upon the monetary 
value of the equipment and the type of procurement action 
(competitive or sole source). On 12 April 197"? these 
approval levels and thresholds were modified by SECNAVNOTE 
5230. The levels and thresholds are shown by Figure 3.1. 

These then are the major instructions and 
regulations that governed the management and acquisition of 
ADP resources during the initial stages of the effort to 
automate the NFCS procurement process. 
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Type Approval 



Level 1 Level 2 Level 3 



A. General Purpose ADPB 
(Sole Source) 

Exceeds $500,000 purchase X 
Op to $500,000 purchase X 

Op to $100,000 purchase 
(non-CP 0) 



B. General Purpose ADPE 
(Competitive) 

Exceeds $ 1 M purchase X 

Op to $1 a purchase X 

Op to $200,000 purchase 



Assistant Secretary of the Navy (Financial Management) 



Level 2 

Chief of Naval Operations 
Director, DON ADP Management 
Commandant of the Marine Corps 



Le ve 1 3 

Deputy Comptroller of the Navy 

Director of Civilian Personnel 

Chief of Naval Research 

Chief of Naval Material 

Chief, Bureau of Medicine and Surgery 

Commander, Navy Military Personnel Command 

Commander in chief, 0. S . Atlantic Fleet 

Commander in Chief, U. 5 . Pacific Fleet 

Commander in Chief, U. S . Naval Forces, Europe 

i j 



Figure 3.1 DON Approval Levels and Thresholds for ADP 
(Ref. 8) 



C. PROCESS FOR ACQUIRING ADP RESOURCES 



It should be quite evident at this point that there are 
two separate sequential processes for acquiring an AD? 
system within the Navy. The first requires that the 
requesting command analyze and justify the proposed system. 
This involves exhibiting that the system aee^s an 




X 



Level 1 
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operational requirement and then justification of the 
system’s technical and economical viability. The Navy’s 
vechicle for providing justification in conjuction with 
system planning is called an Automated Data System 
Development Plan. The plan has two parts. The first part 

develops and presents the economic analysis. The second 

part is a milestone progress report. Captain Jan Prokop in 
his book. Computers in the Navy, describes the plan as 
follows: 

The ADS Development . Plan is intended to be a 
comprehensive, detailed justification of ADS 
development conversion, or major revision propo- 
sals. As such, it represents the documantat ion 
required for approval of such actions. It must 
therefore present a well-defined proposed course 
of action, with clearly identifiable qoals and 
criteria for measuring progress, in a level of 
detail consistent with the scope, cost. and 
complexity of the effort . . . The ADS 

Developement plan is designed to answer these 

fundamental questions: (1) where are we? (2) Where 

do we want to be? (3j what specific steps are we 
going to take? (4) Who is resoonsible? ,(5) What 
resources are required? (6) 'Is the trip worth- 
while? As such, each ADS must be specifically 
defined, with the impact on mission related objec- 
tives quantifiably identical; costed; and proven 
beneficial in terms of the effectiveness with 
which it will satisfy the objectives of the func- 
tional operations to be supported [Ref. 9: p. 30]. 



The level at which this plan is reviewed and approved 
depends upon the cost of the system and the command sponsor- 
ship or proponent’s ability to generate high-level interest 
in the system. This is a very significant point due to the 
Navy’s effort in the late 70’s to centralize the decisions 
regarding ADP policy and delegating the responsibility for 
implementation and review to the operational commanders. 
Systems receiving high-level review cause periodic manage- 
ment reviews of alternatives, incurred cost, and milestones. 
This adds to increased effectiveness in the acquisition of 
ADP resources. On the other hand, a low interest-low cost 
system is not afforded the necessary management review to 
ensure effective use of these valuable resources. Sometimes 
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thi s is one of the major reasons that systems fail to 
perform as originally planned. 

Upon approval of the plans, the second process begins: 
the evaluation and selection of the equipment. If authority 
to acquire the ADPE is granted by 3SA (DPA) or it comes 
under the exceptions previously listed, ADPSO will normally 
accomplish the selection and acquisition of ADP resources 
requiring Level I or Level II approval. NAVSUP has desig- 
nated other activities which can procure ADPE. These activ- 
ities are the NRCC's in Washington, D.C. and Long Beach, 
Ca. ; and local purchasing offices of the Naval Material 
Command (NAVMAT) RDT5E activities as designated by NAVMAT. 
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IV. 



TH 3 AUTOMATION EFFORT 



BACKGROUND 



As pervious ly mentioned in Chapter One, NAVSUP first 
initiated actions to automate the procurement process at the 
major NFCS activities in late 1974, However, they were by 
no means the first source to advocate or use ADP resources 
fcr the procurement function. As early as 1961, Howard T. 
Lewis, professor emeritus of the Harvard Graduate School of 
Business Administration, when describing the future of the 
purchasing process stated, 'There will be big changes in 
dealing with stock, inventory, and order-placing responsi- 
bilities. This will come about as a result of bet- er 
management comprehension of the nature and relationship 
between these activities, and a greater use of automatic 
data processing' 1 [Ref. 10: p. 15 ]. Again in 1964 , J. Weding 

and C. D.iamond addressed the issue in their article, "Buy by 
Computer", published in the Harvard Business Review that 
year. They indicated that relative to other functions 
within industry and government, the procurement function had 
consistently been slow to apply modern management techni- 
ques; therefore, use of ADP resources. They further indi- 
cated that the procurement organization should design, 
operate, and control their own automated system sc as to 
obtain the type of information important for effective 
procurement management [Ref. 11: p. 109], 

In 1966, Achelleas Kollios and Joesph Stempel in their 
book. Pur ch asi ng and EDP, discussed the issue of utilizing 
EDP in the purchasing function. In particular, they 
described in detail the integrated automated procurement 
system used at the Aviation Supply Office (A50) . This 
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system basically consisted of an automated ordering function 
integrated with financial and inventory management control 
programs [Ref. 10: pp. 69-90]. 

On 4 September 1969, NSC San Diego implemented an 
Automated Local Purchase Support system (ALPS). The system 
consisted of three major data files; (a) FSN/Part Number 
File, (b) Supplier Name and Address File, and (c) Automated 
Follow-up File. The system automated the purchasing of cont- 
rolled local purchase items and items under existing 
contracts [Ref. 12: p.8]. 

By October the following year, the small purchasing 
function at various NSC' s was being automated through 
locally developed systems. However, none of these systems 
could be classified as a complete integrated procurement 
management information system. During this time period, the 
Fleet Material Support Office (FMS3) , having overall respon- 
sibility for design of uniform automated data processing 
procedures and programs, initiated work or. a system that 
would integrate the fragmented programs of various activi- 
ties into a comprehensive information system. The system 
would be divided at three different levels; (a) Inventory 
Control Points, (b) Navy Stock Points, and (c) Fleet Units. 
The development of one system apoLicable to these three 
levels was considered to be beyond the scope of the 
resources available at that time [Ref. 13: p.125]. 

Another example of automating a procurement process was 
exhibited by Lieutenant Kenneth Patterson, SC, USN, in his 
master’s thesis titled, "An Information System for the 
Management to Navy Procurement". LT. Patterson proposed a 
model that attempted to solve problems that procurement 
managers have in accumulation, digestion, and dissemination 
of procurement information [Ref. 13: p.125]. The system was 
called ASPIRE which is the acronym for Automated Status of 
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Purchase Information Recorded Electronically. It was er.vis- 
sioned that ASPIRE would be a totally integrated system, 
exportable to all procurement activities. Subsequent to the 
publishing of LT. Patterson’s thesis, ASPIRE was implemented 
at NSC Puget Sound in Bremerton, Washington to undergo 
testing. 

As •‘■he market for electronic data processing equipment 
and software began to expand, so did the number of systems 
used by NFCS major activities for the purpose of procure- 
ment. There was PROMIS (Procurement .lanagement Information 
System) used at NSC Charleston and the WANG system used a 
NRC 0 Long Beach, in addition to ASPIRE at NSC Puget Sound 
and ALPS at San Diego. As the internal and external 
requirements increased and the benefits of automation became 
known, procurement managers began to automate the procure- 
ment process at their activities. This led to various unre- 
lated systems, none of which were totally integrated. 

By 1974, NAVSUP began exploring alternatives to improve 
the total responsiveness of the procurement process in addi- 
tion to resolving the continued personnel reductions 
plaguing the various supply activities. Automation of the 
procurment process at the NFCS activities was considered to 
be one alternative solution to their problems. In recogni- 
tion of this alternative, NAVSUP initiated several efforts 
to develop an automated procurement system, refered to as 
APADE (Automation of Procurement and Accounting Data Entry 
System) . 

3. APADE I 

In April of 1975, a funded research and development 
project was initiated at two pilot test sites to determine 
the feasibility and cost effectiveness of converting the 
existing manual process of preparing formal procurement 
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documents to an automated system utilizing a minicomputer. 
The test sites selected were two in/entory control points; 
Aviation Supply Office (ASO) and Ships Part Control Center 
(SPCC) . 

1 . Sys te m 

The research and development effort consisted of 
using Data General Nova 800 minicomputers for procurement 
document preparation. They were mainly RFP's, IFB's, and 
purchase award documents. The system worked by a typist 
interacting with the minicomputer through the use of a CRT 
display unit. The operator would answer various questions 
that were programmed for each type of document. The informa- 
tion would then be printed out by a large Spectra 70 
printer. This printed document had to be reduced before 
being mailed out to the contractors. 

2 . Re su lts 

The R&D project met with only limited success. 
However, the test indicated than the potential existed for 
greater improvements in this area as well as in other labor 
intensive procurement functions. 

As and outgrowth of the RSD project, NAVSOP tasked 
FMSO in December 1975 to review locally developed automated 
purchase systems at various MFCS and other DGD activities in- 
addition to commercial sources for possible standardization 
and exportation to the NFCS. The following is a list of 
those systems evaluated: 
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4 . 



SAMMS - Defense Logistics Agency's Standard Automated 
Material Management System, 

5. PADS - DARCOM's Procurement Automated Documentation 
System, 

6. Cl AP S - Air Force's Customer Integrated Automated 
Procurement System, 

7. MOHAWK Data Sciences 21/50 System, 

8. IBM PROFS Micro Computer System, 

9. WANG Data Processing and Word Processing "Vs" System, 
and 

10. Xerox's 860 Word Processing System. 

FMS 0 reported that these unique purchase systems were not 
sufficiently comprehensive and that exportation of any 
existing system was not feasible, even for a short term. 

Following the system review, the need for the design 
and development of an automated procurement system, which 
addressed the total needs of the NFCS activities became 
apparent. In 1976, fiscal year 1977 funds were granted under 
the Navy Productivity Enhancement Program to develop APADE 
for system-wide application. 

C. APADE II 

1 . Project Initializer ion 
a. Command Plan 4 338 

In April 1977, NAVSU? 32, Deputy Commander for 
Procurement Management, submitted Command Plan# 338, 
Automation of Procurement and Accounting Data Entry (APADE), 
to the Commander Naval Supply Systems Command. 
Subsequently, the plan was revised and resubmitted on 13 
June 1977. 

The purpose of the plan was to provide manage- 
ment information concerning the project. The overall goal 
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was 



of the project, as stated by the plan, 
automated procurement management system 
procurement activities. Specifically, the 



to provide an 
to major field 
plan stated that. 



The APADE project will provide an automated procurement 
management system to 11 NAVSUP procurement activities 
and 18 other major field purchasing activities with 
capabilities for PR/requisicion tracking, automated 
document preparation, and management information 
reports. The system will also have source data automa- 
tion capabilities to enable transfer of pertinent 
procurement data to interfacing, dependent financial and 
supply data systems without manual intervention. 
Overall effect will be to improve field procurement 
function, reduce cost of procurement operation, reduce 
procurement administrative lead time, provide more 
responsive support to NFPS (NFCS) customers. 



Additionally, the plan listed the following 
tasks which contribute to accomplishment of the goal: 

1. Finalize system policy concepts, 

2. Develop system design specifications, 

3. Identify hardware requirements and software require- 
ments, 

4. Develop requirements documentation, 

5. Obtain hardware requisition approval, 

6. Procure hardwar e/soft ware , 

7. T c st and implement at prototype site, 

8. Implement at remaining NAVSUP activities, ar.d 

9. Implement at designated non-NAVSUP activities. 

The Command Plan specifically tasked FMSO with providing 
analysis, contracting, implementation and maintenance 
support for the APADE project. A copy of the revised 
Command Plan is provided in Appendix 3. 

Upon reviewing this plan, it is evident that the 
drafting of the system design specifications was estimated 
to take only one month. Additionally, the total system 
development, including acquisition of all applicable hard- 
ware and software, was estimated at six months wirh testing 
and implementation at the prototype site to be completed 
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only nine months after project initialization. These appear 
to be unrealistically short time frames, given the myriad of 
higher agency requirements discussed in Chapter III. 

b. Organization 

Following the initial submission of Command 
Plan# 338, the general management responsibilities within 
the various commands began to formalize. The responsibility 
of functional sponsor for the AP ADS project was assigned to 
Deputy Commander for Contracting Management (NAVSOP 02). 
Project Management was assigned to the Deputy Commander for 
Plans, Policy, and Programs Development, Financial Systems 
Development Division (NAVSUP 0 '4 4 ) . This Division would be 
responsible for planning, funding, executing, and monitoring 
APADE II development, initial implementation and system 
maintenance. NAVSOP 041, Programs Control and Development 
Division would provide support by scheduling and performing 
automated data processing reviews and assisting in the 
preparation of various development plans. 

FMSO, as the NAVSUPSYSCOM agency responsible for 
design of uniform automated data processing procedures and 
programs, would perform the technical management of the 
project. They would be specifically tasked with ensuring 
that the Functional Description (FD» and Data Requirements 
Document (DRD) accurately reflected the needs of the 
procurement community and were precise enough to aid in 
system development. Additional responsibilities included 
those addressed in the Command Plan. 

c. Systems Policy and Concepts 

As required by the Command Plan, NAVSU? 02 
published the Systems Policy and Concepts Policy document in 
Aprill 1977. The purpose of this document was to outline 
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The document 



the requirements for the APADE II system, 
included the following main features: 



1. Purchase request (PS)/ requistion tracking/document 
control, 

2. Automated preparation of standardized, formal procure- 
ment documentation, 

3. Source data automation, 

4. Procurement management information reporting, 

5. Procurement interfere with existing data systems, and 

5. Real time, interactive processing. 

Additionally, this document specifically stated 
that, "APADE II will provide a standardized baseline for 
automation of procurement processes throughtout the Navy 
Field Procurement System. Due to the broad range of activi- 
ties involved and the significant differences in existing 
interrelated (e.g. supply and financial) management systems 
in operation at various activities, APADE II design must be 
sufficiently flexible to accommodate such factors" [Ref. 14: 
p. 3-4]. 

d. ADS Development Plan 



In addition to the System Policy and Concepts 
document, NAVSOP also initiated work on the Automated Data 
System Development Plan during the same time frame. 
However, this document was not officially approved by the 
CND until 12 October 1977. This document, as discussed in 
Chapter Three, provided the j ustif ica tion of the system's 
technical and economical viability. 

The first part of the ADS plan was the Economic 
Analysis. In analyzing the automation of the procurement 
process, five alternatives were considered. They were: 



1. Continue current system. 
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2. Contract service, 

3. Share or use existing facilities, 

4. Develop a central procurement system, and 

5. Develop a uniform minicomputer system at each proposed 
site. 

Alternative One was eliminated since it had 
previously been shown that the curent system was slow and 
severly impacted upon the responsiveness of the system. The 
second alternative was not feasible because APADE II was 
intended for operation by ncn-ADP personnel with minimal 
training required for system operation. It was further 
estimated that system operation would not exceed 0.5 person 
hours per activity per day. Therefore, it was not practical 
to contract for this small work load. Additionally, it was 
planned that software maintenance and enhancements would be 
performed by FMSO. Alternative Three was eliminated since 
existing facilities were considered to be saturated and did 
not allow the objectives of the system to be met. 

Both Alternatives Four (4) and Five (5) were 
considered to provide equal benefits; however, the central 
procurement system, alternative 4, would require additional 
manpower for system operation in addition to expanded facil- 
ities for environmental protection. Alternative 4 was 
eliminated as the greater cost/equal benefit alternative. 

Alternative 5 consisted of locating minicompu- 
ters at 12 operational sites plus one test bed minicomputer 
site. The software would be uniform across the procurement 
system. The system would be adaptable to volume and varying 
personnel requirement: s at the sites. Each system would have 
one central processor with 256K memory, multiple disk units 
with up to 10M bytes of storage, one magnetic tape unit, one 
card reader, one to two line printers, and up to 4 cathode 
ray terminals. The software developers would provide 
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turnkey programming training and would be required only for 
maintenance at FMSO. Some operational training was consid- 
ered to be necessary, but the system could be operated by 
existing employees currently in the activities. The system 
would also produce tapes which would interface to other data 
bases affected by procurement operations. 

Specifically, A FADE II would be capable of 
interfacing with certain existing supply, financial, and 
contract administration systems as necessary. These systems 
include: Uniform Automated Data Processing System 

(UADPS-SP) , Naval Sea Systems Management Information System 
(NAVSEAMIS) , Navy Uniform Vendors Evaluation Program 

(NUVEP) , Military Standard Contract Administration Procedure 
(MILSCAF), Shipboard Uniform Automated Data Processing 
System (SUADPS) , and the Integrated Disbursing and 
Accounting Data Exchange (IDA-DX). 

The equipment would require no special environ- 
ment. The CRTs would be placed on desk, utilizing existing 
work space. The central processing unit (CPU) , disk, and 
magnetic tape units would be mounted on racks. Line prin- 
ters would be located near the supervisor's office. 
Overall, Alternative 5 was designed to meet the needs of an 
automated procurement system in the areas of: 

1. Procurement operations, 

2. Report generation, 

3. Document preparation, and 

4. Source data automation. 

The total cost of the minicomputer system was 
estimated at $159.8 million, shown in Table I. Based upon 
an inflation rate of 4.7 percent per year, the total present 
value savings was estimated at $4,265 million over the 
estimated eight year life of the system. Payback of the 
investment was calculated at 1.97 years. 
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r ABLE I 



COST APADE 
Type 

I 1 
Development 
ADP . 3 

Nor - ADP 0 

Operational 



APADE Estimated Cost 



♦APADE I I-Pr o ject Y°ars 



2 3 

0 3 

0 0 



4 5 

0 0 

0 0 



6 7 

0 0 

0 0 



Total 

8 

0 .3 

0 0 



ADP . 09 16.5 17. 3 18.2 18. 9 19. 8 20.8 21.3 22.8 156.3 

Non- ADP . 04 .2 . 2 . 2 . 3 . 3 . 3 .3 .3 2.1 

Equipment. 111.40 0 0 0 0 0 0 1.4 



Total 

Sysrem .24 18.4 17.5 18.4 19.2 20.1 21.1 22.1 23.1 159.8 

* Inflated at 4.7T C per year (CHNA7MA T ltr. 26 Oct. 1976) 



The economic analysis exhibited that Alternative 
5 provided for automation of most procurement operations at 
a relatively low cost for equipment, software, and support. 

In conducting the economic analysis, the ADS 
development plan projected a starting date of the first 
quarter fiscal year 1978. Project completion was estimated 
at ADS aDproval plus 18 months. Figure 4.1 provides the 
planned ADS locations with installation date and ADPE to be 
uti lized . 

The second part of the ADS Development Plan 
consisted of the Milestone Progress Report. This report 
exhibited the same proposed task and completion dates as did 
Command Plan# 338, Appendix 3. 
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Location 



AD PE 

Sets CRT Disk: 
Units 



Installation Date 
(ADS apDroval olus 
months) 



Developer 1 4 

NSC Oakland 1 '4 

SPCC 1 4 

ASO 1 4 

NSC Charleston 1 4 

NSC Norfolk 1 2 

NR PO Philadelphial 2 

NR PO Washington 1 2 

NRPO Lona Eeach 1 4 

NSC San Diego 1 2 

NSC Puget Sound 1 2 

NSC Pearl Harbor 1 2 

NRPO Newport 1 2 



?M SO ‘ Development 



4 

5 
5 
2 
5 
4 
1 
1 
3 
3 
2 
3 
1 

Set 



3. 

5. 

12 . 

12 . 

13 . 

13. 

14. 

14. 

15 . 
15. 
15. 
15. 
17. 
17. 



0 

5 

0 

5 

0 

5 

0 

5 

0 

5 

0 

5 

0 

5 



*One set is comprised of one aach of the following: 
CPU 

Core Memory 

Disk Units as indicated above 
Tape Unit 
Line Dr in ter 
Card Reader 

Number of CRTs as indicated above. 
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Figure 4.1 site Location and Installation Estimates (ADS 
Development Plan) 



2. Project Acoro val and Ta skin 

On 8 June 1977, UAVSUP 044 reemphasized to FMSO the 
following reguired actions: 

1. Develop system design specif ica tions by 1 June 1977, 

2. Award a contract by 6 June 1977 to identify hardware 
and software requirements, 

3. Identify hardware and software requirements by 15 July 
1977, 

4. Develop requirements documentation by 30 July 1977, 

5. Procure hardware/software by 3D September 1977, 

5. Implement and test at NSC Oakland, and 
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7. Implement at remaining stock points by 30 September 
1978. 

Additionally, NAVSUP 044 classified the project as mandatory 
with an assigned priority of 7a. This priority indicated 
that the APADE effort was part cf another major project that 
was seventh on a priority list of projects assigned and 
approved for FMSO during that fiscal year. 

On 30 June 1977, the Assistant Deputy Commander, 
Plans, Policy and Program Development, NA7SU? 049, forwarded 
the approved Command Plan # 338 to FMSO's Commanding Officer 
for assignment of the responsibilities and tasks as previ- 
ously mentioned. NAVSO? 049 emphasized the fact that NAVSUP 
04 was responsible for project completion and sucess of the 
program hinged on the ability of NAVSUP to contract for 
hardware by 30 September 1977. 

3. Har dwar e Ac gu is it io n 

On 26 July 1977 a delivery order contract was issued 
to Systems Consultants, Inc. (SCI) as a result of an unsoli- 
cited proposal from SCI to FMSD . The contract specifically 
requested that SCI perform the following action if optioned 
by the Government: 

1. Participate in technical conferences with FMSO 
personnel , 

2. Review APADE II design specif ications , 

3. Develop specific equipment and system requirements, 

4. Perform a survey of all available minicomputers suita- 
ble/capable of performing this task, and 

5. Prepare a full system specification. 

With the exception of task five, all actions were optioned 
and completed. SCI provided a set of general system speci- 
fication instead of full system specification as outlined 
abo ve . 
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As a result of the information provided by SCI, FMSO 
informed NAVSUP 049 that APADE II hardware requirements had 
been identified on 16 August 1977. The hardware selection 
was based upon a comparative analysis of minicomputer 
systems from the following commercial manufacturers: 

1. Data General, 

2. Interdata, 

3. Varian, and 

4 . DSC 

The equipment selected was the Interdata System. 
This system consisted of a 7/32 central processing unit 
(256K Bytes), 2 2 M Bytes disk drives, 600 lines per minute 
printers, 400 cards per minute card readers, and video 
display units. Additionally, the following software package 
was accepted as part of the system: 

1. Operating System OS/32MT, 



2. Compiler Cobol, and 

3. Utilities Tele communications ITAM 32. 

Data Entry HR AC 



On 30 September 1977, the Automatic Data Processing 
Selection Office (ADPSO) issued a delivery order contract, 
N66032-76-D-0004, for the acquisition of the initial hard- 
ware requirements of the APADE II system. This was 
performed in accordance with SSCUAVINSI 5236. 1A, 
Specification, Selection and Acquisition of Automatic Data 
Processing Equipment. It was planned that Interdata proces- 
sors and Deriphial equipment would be delivered, installed, 
and accepted at the rate of two a month until all deliveries 
were completed. The first deliveries started to arrive at 
the prototype and development sites by December 1977. 
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4 . System Deve lo pm ent 

On 16 August 1977, in a latter to NAV3UP 049, the 
Commanding Officer of FMSO voiced the concern that, "we may 
be moving too quickly and have not yet thought out all 
aspects of the APADE pro-ject." One specific area of concern 
dealt with the application software development. There was 
no indication of who would accomplish this effort, i.e., 
FMSO or a contractor. FMSO’s CO advocated contracting out 
this effort due to the lack of personnel at FMSO with the 
needed experience in this area. Additionally, he considered 
that application software development would taka longer than 
the NAVSOP Command plan indicated. He stated that, "FKSO's 
personnel estimated a minimum of six to eight months after 
award of a contract for delivery of a first module, with 
full development taking as long as fifteen months. 

The CO also addressed the issue that no formal plan 
had been formulated for maintenance of the system. He 

emphasized that FMSO would be the best choice, but specific 
resource requirements would be difficult to estimate until 
the application software was designed. In addition, he 

expressed concern that no formal plan presently existed for 
incorporating any on-line interfaces via APADS II. 

a. Request for ADP Services 

On 2 September 1977, FMSO submitted a request 
for ADP services to the General Service Administration (GSA) 
via GSA form 2068, in accordance with the Federal 
Procurement Regulations. ( As described in Chapter Three, 
this is a request for a Delegation of Procurement Authority, 
DPA ) The request provided the description of the minicom- 
puter system that had been agreed upon earlier as the 
minimum equipment configuration. If described the software 
package being procured from Interdata and proposed the 
following personnel requirements: 
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1. One Team Leader Analyst, 

2. Two Computer Systems Analysts, and 

3. Four Programmers. 

The description of requested services indicated 
that FMSO would provide systems specifications from which a 
computer system was to be designed and programs written in 
addition to testing, debugging, and implementation of the 
system at the first site. Additionally, the request 
provided the following system definition: 

The APADE II System shall consist of a standard set of 
equipment and software components configured according 
to the performance chara cter istics required by each or 
the thirteen (13) sites receiving the system. The stan- 
dard equipment and software set shall be adaptable for 
each of the user sites according to the definitions and 
constraints specified herein. 

Further, the request stipulated that APADE II would support 
five system functions. These functions were: 

1. Procurement Tracking, 

2. Procurement Record/History, 

3. Document Generation, 

' 4 . Management Information, and 
5. Telecommunications Interface. 

Each of thes system requirements are summarized in Appendix 
C. 

On 6 September 1977, GSA notified FMSO that it 
chose not to issue a Delegation of Procurement Authority. It 
further directed that the work would be performed through 
the use of an existing AD? Service Contract, negotiated by 
GSA, Atlanta, for the Interagency Data System Facility 
(IDS?) located in Huntsville, Alabama. 

Since 1967, GSA has maintained the IDSF at 
Huntsville and administered an ADP service contract with a 
commercial vendor. The major function of this facility is 
to provide a convenient and economical source of systems 
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analysis and programming talent for small dollar value (less 
than $250, 000) requirements of Federal agencies, especially 
when a fast start-up is desired. 

IDS? functions as the project monitor. In 
general, they provide spare, supplies, telephone, etc., to 
the contractor, forward contractor estimates in response to 
request for task order amendments, and verify contractor 
charges against the project task orders. However, all 
Contracting Officer responsibilities are retained by the GSA 
regional office in Atlanta. 

It should be understood, that these AD? tech- 
nical support service contracts are nothing more than a time 
and material, requirement type contract. GSA-IDSF orders 
labor hours at a specified rate and naterial at cost. This 
type of contract requires constant monitoring to er.sur a 
efficient and effective use of government resources. 

On 8 September 1977, PMSO requested an estimate 
of time and cost to perform -he services outlined on the GSA 
Form 2068 from IDSF Huntsville. The initial GSA estimate 
for the total APADE II application software was approxi- 
mately $248,000 with an estimated completion date of April 
1979. 

b. Memorandum of Understanding 

On 21 October 1977, a Memorandum of 
Understanding (MOU) between GSA-IDSF and FMSO was signed. 
The general purpose of the MOU was to establish a working 
agreement through which GSA-IDSF would provide AD? technical 
support services on a reimbursable basis to FMSO. 
Specifically, GSA-IDSF would issue task orders to the 
support contractor based on the work requirements and speci- 
fications submitted by FMSO. Mo single task order issued by 
GSA-IDSF could exceed $250,000 for total support cost. All 
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alterations and modifications of amendments required prior 
approval by FMSO. The performance period would be governed 
by the requirements and specif icaticns for each individual 
task as prescribed by FMSO. 

The initial task orders to be accomplished were: 

1. System Specifications, 

2. Data Base Requirements Document, 

3 . Test Plan , 

4. Program Specification s, 

5. Program Coding and Tasting, 

6. System Integration, 

7. Acceptance Testing, 

3. User Manual, 

9. Training, and 

10. Quality Assurance Program. 

A summarization of each task is provided in Appendix D. 

It should be noted at this time that Task One, 
System Specifications, was to be based upon the APADE II 
Functional Description being provided by FMSO. 

As a result of the MOO , a project order was 
issued on 21 October 1977 to 3SA-IDSF for APADS II applica- 
tion software development. Funds amounting to $193,000 were 
provided for the initial ten tasks in addition to an evalua- 
tion of possible use of a file management , inquiry and 
retrival system and taleccmmunica tions package, TAPS 
(Terminal Application Processing System) for use in APADE 

II. System predesign and software evaluation was initiated 
under task orders H587 and H538 by Potomac Research, 
Inc.(PRI), the GS A- ID SF support contractor in December 1977. 
Development hardware was delivered to the development 
contractor, PHI, by 20 January 1973. The hardware was 
finally installed, tested, and accepted by PRI on 31 March 
1978. 
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c. Modular System Concept 

As early as July 1977, modular system develop- 
ment and installation was planned for the AP ADS II project. 
This was first indicated in the 15 July 1977 preliminary 
system design specifications published by FMSO. The modules 
wer e: 
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d. Module I Development 

The task order (H585) under which Potomac 
Research, Inc. (PRI) commenced the developement of APADE II 
was initiated in February 1978. As previously mentioned, 
the task required the contractor to prepare system specifi- 
cations and succeeding deliverables from the government 
provided FD and DR D. However, these items were not 

completed by Computer Data Systems, Inc. (CDSI) until 15 May 
1978. Therfore, PRI's effort during the interim was based 
on preliminary versions of these documents in addition to 
direct meetings between FMSO, PRI, and CDSI personnel. 

For the next four months, from February until 
May there were no indications of any problems with the 
development effort. PRI was reporting their work perfor- 
mance every two weeks by submitting task order activity 
reports to FMSO. Additionally, two meetings were conducted 
between the contractor and FMSO personnel during that 
period. On 19 May 1978 PRI indicate! that they were experi- 
encing difficulty with the TAPS package and the Interdate OS 
32 editor. This was also the first time that they reported 
the use of over-time. As of 1 4 Jul/ 1 978, they had not yet 
completed system testing of Module I. Implementation on 
Module I at the prototype site was scheduled to commence on 
17 July 1978. 

e. Prototype Testing 

NSC Oakland was selected as the prototype test 
site because they were experiencing sever problems in the 
area of small purchases. During that year, approximately 58 
percent of the procurement department’s personnel were 
devoted to small purchases. They were receiving from 2509 
to 3000 purchase requests per week for non-standard, low 
dollar-value (less than 310,000) items. This eventually 
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resulted in a weekly output of 1200 to 1500 award documents. 
Because of the manual methods employed to collect data on 
work load distribution, buyer production, and requisition 
status, management control of the procurement process 
involving this many requisitions was greatly reduced. 
Approximately 600 customer inquiries were being received 
weekly which proved to be a costly and time-consuming manual 
task [Ref. 15: p.9]. 

Since Module I was specifically designed to 
provide the management data needed to control and simplify 
small purchase processing, NSC Oakland would provide an 
excellent test of the module. In addition, NSC Oakland had 
budgeted for the personnel decrease associated with the 
productivity increase to be accrued with APADE II for both 
?Y 79 and FY 80. 

Implementation of Module I was originally sche- 
duled from 17 July thru 28 July 1973. Although implementa- 
tion was initiated on 17 July 1978, it was not fully 
Stabilized until February 1979. This was due to several 
problems. The implementation suffered a series of software 
and hardware problems which required several changes to the 
initial software design in addition to requiring more hard- 
ware. FMSO reported that the software had to undergo exces- 
sive debugging during the implementation effort. This 
entailed many long hours of reprogramming by contractor 
personnel. Another problem encountered was that the 
GSA-IDSF ADP technical support contract expired on 30 
September 1978. Cr. 12 August 1973, FMSO was informed the 
follow-on contract had been awarded to Computer Sciences 
Corporation (CSC) and would become effective 1 October 1978. 
Although the majority of personnel and especially the 
project leader, were hired by the new contractor, it caused 
disruption to the implementation process. 
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Or. 2 January 1979 , the contractor's project 

leader (the only project leader since the project initia- 
tion) abruptly left the contractor. Only at that time was 
it discovered that no substantiating documentation for any 
modules existed. The project leader had mentally controlled 
all development efforts and the application software without 
providing any written documentation of his undertakings. If 
required the following two months to recover lost progress 
and rebuild system documentation. In addition to the docu- 
mentation, FM SO considered that adequate test plans and 
procedures had not been established nor used. It expressed 
that the majority of the problems encountered were discov- 
ered on site, impacting on the implementation process. 

Overall, the results of the problems encountered 
were that prototype testing became nonexistent and implemen- 
tation by trial and error was the game plan. By 20 February 
1979, Module I of APADE II had been implemented at NSC, 
Oakland. Development on the remaining modules continued 
under the a 00 with GSA-IDSF. 

f. Second Test Site 

On 12 February 1979, the Officer In Charge (QIC) 
of NSCO Washington, D.C. requested that Module I of Apade II 
be implemented at his activity. He stated that NRCO 
Washington had an urgent need for an improved requisition 
tracking system. The OIC considered that since the hardware 
for APADE II had been received and installed at his 
activity, implementation of Module I was a viable 
alternative [ Hef . 16: p. 1]. 

The systems test plan required that FMSO recom- 
mend to NAVSUP 044 when a module was ready for implementa- 
tion at the other proposed sites. Although this had not 
been done, it was decided in March that the results at NSC, 
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Oakland were sufficiently encouraging to justify a second 
prototype test at NRCO Washington, D. c. The expansion of 
Module I to a second prototype was justified by emphasizing 
the difference in procurement volume and type between a NSC 
and a NRCO. The NRCO mainly deals in a low volume, high 

dollar value environment whereas the NSC deals in a high 
volume, low dollar value environment [Ref. 15: p.11]. 

3y the end of April 1979, CSC had generated the 
Module I system for the hardware configuration at NP.CO, 
Washington. However, no specific test plan stating the 
goals for additional testing had been developed. Module I 
was implemented at NRCO by FMSO personnel in May 1979 
without assistance of contractor personnel. The implementa- 
tion effort proved more sucessful than had been experienced 
at Oakland. This was mainly due to the availability of a 
stablized software system and the volume of small purchase 
actions was only a fraction of that at experienced at 
Oakland. In addition, no increased productivity had been 
forecasted in NRCO's budget. 

g. Contract Administration 

After the severe problems encountered during 
system implementation at NSC, Oakland, FMSO began to monitor 
both GSA-IDSF and CSC more closely. Although the MOU 
clearly held their responsibility as tasking and funding the 
project, with final acceptance authority, FMSO began to 
become more involved with the actual contractor's perfor- 
mance. The following co r respondents are seme examples of 
the increased interest in administration of the contract by 
FMSO. 

In a letter dated 20 February 1977, to GSA-IDSF, 
the FMSO project officer for APADE II requested tha-: 
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1. CSC review all data base, system/subsystem, and 
program specifications of Module I to ensure proper 
documentation, 

2. CSC provide complete documentation for Modules II and 
III for review and approval before any programs are 
written , 

3. CSC fully staff the project as exhibited in their 
estimates, and 

4. CSC exercise greater management control to assure all 
programs conform to applicable standards. 

In March 1979, CSC notified FMSO that the 

revised estimate for completion of Module II was August 

1979. Since that estimate would put the project a total of 
nine months behind the original schedule, FMSO stated that 
CSC 1 s projected completion date was unacceptable. In a 
letter to GSA-IDSF dated 14 March 1979, ?MSO‘s CO indicated 
that although over 2950 man-hours have been reported to 
develop system/subsystem specifications, program specifica- 
tions and other documentation on Module II through 20 
January 1979, little progress has been made on Module II. 
He requested that it be determined what had to be done to 

complete Module II by May 1979. In addition, as a result of 

the alleged cost to date, he requested GSA audit man-hours 
expended versus amount of accomplishment. 

The response letter from GSA-IDSF cn 6 April 
1979, indicated that CSC was not required to report hours 
expended by module since GSA issued the project as a single 
task order. Additionally, the estimated completion date for 
Module II was considered reasonable since it was being 
developed under a mere formalized manner than Module I. 
This was in reference to the approvals tha + were required by 
FMSO’s letter dated 20 February 1979. 
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It was approximately this same time period that 
CSC recommended implementation of Module II in two phases: A 
and B. Phase A would contain those capabilities and files 
considered a priority for implementation at NSC, Oakland. 
Phase B would contain the remaining files, document 
processing and the Integrated Disbursing and Accounting 
(IDA) interface. Module IIA was estimated to be completed 
by CSC on 31 July 1979 with implementation at Oakland in 



August 1979. 

3y June 1979, over S303,900 had been spent on 
the application software development. The project originally 
scheduled for an April 1979 completion date had no firm 
completion date in sight. 3ecause of development and imple- 
mentation delays, cost overruns. Naval Audit Service recom- 
mendations and requirements associated with 
multiple-activity standard systems, the CNO requested, "that 
all new APADE II initiatives be held in abeyance pending a 
comprehensive evaluation of the project" [Ref. 17: p. 1]. 
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V 



EVALUATION AND CONSTRAINTS 



A. NAVDAC EVALUATION OF APADE II 

On 11 June 1979, the Chief of Naval Operations directed 
the Naval Data Automation Command (NAVDAC) to conduct an 
evaluation of the APADE II project. He further requested 
that the evaluation report be completed no later than 12 
September 1979. On 10 September 1979, after three months of 
thorough evaluation, NAVDAC reported their findings and 
recommendations concerning the future of the APADE II 
project. 

1 . NA VDAC Fi ndi ngs 

NAVDAC's evaluation report indicated several areas 
in which serious problems had developed and contributed to 
the projects current condition. Those areas were: 

1. Initial pro jeer planning, 

2. Contractor, 

3 . Design, 

4. Implementation, and 

5. Project monitoring. 

The following discussion is a summary of each problem area 
as reported b 7 the NAVDAC evaluation team. 

a. Initial Project Planning 

Upon reviewing the initial approval process and 
planning of the development process, NAVDAC considered that 
the projected schedule was overly optimistic in that the 
magnitude of the APADE II project was not fully understood. 
Additionally, they considered the system design concsDts 
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were not sufficiently defined to justify early acquisition 
of AD P hardware. 

NAVDAC also indicated that a major failure in 
rhe early stages of project planning was in defining the 
requirements of the application software development 

contractor. Specifically the fact rhat the contractor 

performed software development before the Functional 
Description (FD) and Data Requiremnet Document (DR D) were 
completed. This required interpretation of the functional 
requirements by the development contractor and subsequently 
resulted in disputes as to the consistency between developed 
program and functional requirements. In addition, the 
development contractor had no procurement expertise among 
his personnel. 

Another flaw in project planning was a lack of 
detailed test plans describing what tests were to be 
conducted and by whom. The Test and Implementation Plan did 
not provide for test data recording, reporting, evaluating, 
or approval procedures. 

b. Contractor 

NAVDAC considered the change of the GSA-IDSF ADP 
Support contract from PRI to CSC, combined with the abrupt 
departure of the contractor 's project leader, significantly 
contributed to the delay in software develpoment. However, 
they indicated that coordination with and control of the 
contractor had just as much impact on inhibiting the devel- 
opment process. They cited the failure of GS A and FHSO to 
establish intermediate milestones for the contractor and GSA 
to monitor progress and penalize late delivery as contri- 
buting factors. Also, the geographic location of FNSO, GSA, 
the Development Site, and the Protot/pe site impeded organi- 
zational communications. To this statement, they referenced 
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frequent communications between CSC and FMSO concerning 
interpretations of the FD and system requirements without 
informing GSA-IDSF. This led to verbal changes, additional 
labor commitments, contractor claims, and disputes over the 
veracity of these claims. 

c. Design 

NAVDAC stated that the selection of TAPS as the 
file management, inquiry and retrieval system and telecommu- 
nications package restricted APADE II design. They indi- 
cated that designing an efficient application system in the 
TAPS environment required an extensive knowledge of TAPS's 
capabilities and limitations. TAPS was a relatively new 
product and both PHI and CSC had no prior experience with 
this package. NAVDAC reported that contrector personnel 
possessed only a limited understanding of the Interdata 7/32 
operating package, OS/32NT. 

The system design did not allow for any recovery 
capability. The only back-up capability was provided by 
daily copving of all data and index files to magnetic tape. 

NAVDAC also considered that the system was being 
developed in an excessively fragmented fashion. Although 
the original four module approach was acceptable, fragmenta- 
tion of design was resulting because difficult aspects of 
certain modules were being transferal to later module devel- 
opment or formed into a separate module. 

NAVDAC also addressed the fact that no 
conrraczor or Navy personnel with adequate hardware experi- 
ence, in general, and Interdata hardware experience, in 
particlular, were included in the project’s structure. 
There were no means to ensure efficient utilization of the 
ADPE selected. 
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d. I mplementation 



On* of the major problems with implementation 
was the decision to rush Module I to NSC Oakland. NAVDAC 
stated that, " the system was implemented without adequate 
prior software testing to satisfy an urgent NSC need for an 
automated aid to their small purchasing crisis. Instead of 
helping, the system was a burden to NSC management and a 
resource drain from July 73 through February 1979" [Ref. 15: 
p.33 ]. 

e. Project Monitoring 

In reference to project monitoring, NA7DAC indi- 
cated that management review actions were not initiated when 
the project began to experience problems with implementa- 
tion. They further stated that the ADS development plan was 
not updated when the planning estimates proved inaccurate. 
Additionally, they cited the December 1977 Management Plan 
as no longer current. 

They also indicated that although the current 
APADE II project is over cost and behind schedule, no 
formalized plan had been developed to remedy the problems 
and complete the project. In addition, APADE II was an 
unfunded requirement for FY 80 and out years in the 
NA7S0PSYSC0M ADP budget submission. 

Overall, NA7DAC considered that the problems 
were of a common origin: execution before or without 

adequate planning. 

2. Reccm mend tions 

The following discussion is a summary of the recom- 
mendations from NA7DAC that were provided to the CNO on 10 
September 1979. 
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First, NAVDAC recommended that no APADE II initia- 
tives (development, acquisition, or implementation) be taken 
prior to completing the following: 

1. A major revision to the APADE II ADS development plan, 

2. Performance analysis and benchmark testing of hardware 
configuration at NSC Oakland to accurately identify 
the hardware requirements that have only been esti- 
mated, and 

3. A review of the FD/DRD prior to further development 

with a Design Review Board performing a final review. 

It was also recommended that APADE II ?Y 80 and FY 

81 budgeting requirements be prepare! as quickly as possible 
for the Chief of Naval Material’s (CHNAVMA?) consideration. A 
third recommendation was to continue with software develop- 
ment and documentation through the completion of Module TIA. 
In addition, it was recommended to implement Module IIA at 
the current prototype sites, and at limited additional 
NAV SUPS YSCOM sites following CHNAVMAT approval of prototype 
test results. 

NAVDAC’s fourth recommendation stated that AD? 
Readiness Reviews at the activities not reviewed should be 
done and documented for CBN AVMAT apDroval. Finally, if the 

CNO should ultimately approve continuation of APADE II 

development, the following additional recommendations were 
submitted. 

1. Formalize test and aoceptance procedures, 

2. Premature implementation should be avoided, 

3. If software development is continued under contract, 
the contractor/FMSD relationship should be more 
formalized, 

4. Provide basic and advanced training in capabilities 
and limitations of TAPS to development programmer/ana- 
lysts, and 
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5. Acquire data recovery capability prior to full APADE 
II implementation. 

B. CNO CONSTRAINTS 

Subsequently, the CNO reviewed the NAVDAC report and 
provided recommendations in his letter dated 1 November 
1979. This letter placed a number of constraints upon the 
APADE II, specifically that : 

1. Implementation of Nodule IIA would be restricted to 
the two prototype sites, NSC Oakland and NRCO 
Washington, D.C. and 

2. There would be no further development, beyond module 
IIA. 

These two constraints would remain in effect until the 
following conditions were satisfied: 

1. Submission and approval of a new ADS plan including a 
cost/benefit analysis contrasting in-house vs 
contractor development, 

2. Completion of a hardware sufficiency analysis to 
determine hardware type and size requirements for each 
site , 

3. Update of the APADE 1 1 FD and DRD following a detailed 
review of these documents, and 

4. Preparation and submission of *PADE II FY 30 and FY 81 
budgetary requirements for CHNAVMAT's consi der anion . 

C. SUMMARY 

The current redesign effort is applying the lessons 
learned from APADE I and II to a Life Cycle Management 
approach developing a totally integrated and exportable 
automated procurement syszem. The modular development and 
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discontinued. 



design approach has been discontinued. The hardware 
requirements are presently being paralleled with the devel- 
opment cf a project to provide new hardware to -he major 
stock points. This project is designated as Stock Point 
Logistics Integrated Communications Environment (SPLICE) . 
The software currently used will be utilized only if it is 
compatable with the new hardware and meets the redesign 
requirements statement. 

The new APADE system will apply the capabilities of 
automated data processing, automated word processing and 
printing, integrated to the extent permitted by current 
technology. The new APADE will provide a standardized 
procurement data processing system designed to provide: 



1. Document control, 

2. Management and Buyer support information, 

3. Automated document and report preparation, and 

4. interdependent system support. 

As previously mentioned, the redesign effort is being 
performed under contract with Bocz-Ailen. Implementation is 
currently estimated for March 1983. 
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VI 



CONCLUSIONS 



For approximately the last 35 years, the U. S. Navy has 
been imvolved in developing and implementing automated data 
system (ADS) within their organization. However, it has 
only been within the past few years that the Navy has 
successfully avoided the major pitfalls associated with 
developing and implementing these systems. 

The major factors contributing to improved management 
decisions within ADS development and implementation are 
historical knowledge, improved technology, and increased 
education in this rapid expanding field. This has lead to a 
change of philosophies among the personnel tasked with 
development and implementation of ADS, in addition to 
improved regulations that provide clear and concise 

guidelines for these personnel. 

One article which provides an excellent view of the ADS 
development process within the Navy was published in 1976 by 
Rear Admiral Frank S. Haak. The article entitled, 
"Brainware versus Hardware” presented six major sequential 
phases for the development of ADS within the U.S. Navy. 
They were: 

1 . Planning, 

2. Technical Development, 

3. Hardware Acquisition, 

4. Programming, 

5. Installation, and 

6. Maintenance. 

The planning phase is initiated by identifying the ADS 
in terms of content, scope, boundaries and external inter- 
faces. This will lead to the system's performance 
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into focus 



parameters and characteristics coming into focus. At this 
time, alternative concepts, designs and technical approaches 
require evaluation to determine their feasibility and rela- 
tive effectiveness in satisfying the system requirements. 
Technically feasible alternatives should then be subjected 
to an economic analysis for selecting the optimum system. 
The planning phase should provide the following products: 



1. A well-defined concept for an automated data system 
capable of satisfying the particular operational 
requirements in a manner consistent with estaolished 
proc edures, 

2. An evaluation of technically feasible alternatives for 
implementing the ADS concept to achieve the best 
possible balance between capabilities and cost, and 

3. An ADS development plan which identifies time sche- 
dules, resources, and management measures necessary to 
convert the concept into an operational capability via 
the selected development approach [Ref. 13: p. 14], 

Admiral Haak indicated that short cuts in this phase 
would probably increase the risk of serious performance and 
economic penalties during the development, operation, and 
maint enanceof the ADS. 

Designing the ADS initiates the technical development 
phase. It requires an "explicit definition, organization, 
and structuring of the data system configuration capable of 
performing all processing functions" [Ref. 18: p.15]. 

Following the designing of the ADS, formulation of detailed 
characteristics, performance requirements, and configuration 
criteria for a compatible computer system should be 
completed. Products of this phase should include: 



1. A comprehensive design for the full-scale ADS, 
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2. A functional description of the ADS which identifies 
the manner in which the design will satisfy the 
requirements of the ADS sponsor, 

3. Detailed specifications for all data bases, files, 
application programs and software interfaces, 

4. ADP equipment specifications for use in the selection 
of appropriate general purpose computer systems for 
the ADS, and 

5. A revised development plan reflecting any significant 

changes and refinements in the milestones schedules, 
resources, requirements, and estimated benefits 

presented in the original ADS development plan 

[Ref. 18: p. 1 6 ] 

Dpon determining that new computer hardware is required, 
proposals are then solicited. The hardware acquisition 

phase should result in a particular computer conf igurat ion 
which has been thoroughly evaluated, tested, and selected on 
the basis of both performance and cost. 

The programming phase is divided into five sequential 
tasks. They are: 

1. Analyzing specifications to identify each program for 
structuring, 

2. Coding into programming language, 

3. Preparing test data and organizing test routines to 
detect possible errors, 

4. Testing each unit, and 

5. Documenting the program. [Ref. 18: p.16-18.] 

After completing these five task, system integration is 
performed by joining individual programs into organized 
modules. The analysis, coding, test planning, and testing 
is reported and recorded as integration is performed. This 
phase should produce the following products: 
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1. Computer programs which perform all functions as 
specified in the ADS requirement statement, 

2. Documentation for proper operation and maintenance of 
the ADS, and 

3. Complete set of test data. [Ref. 18: p. 18.] 

The installation phase envolves the testing, final 
acceptance and certification, and installation of the ADS. 
The testing demonstrates that the ADS operates in an effec- 
tive and reliable manner and conforms to the ADS require- 
ments and objectives. When a ADS is designed for more than 
one site, the test will be designed and conducted as a 
prototype evaluation. 

The maintenance phase is the last phase. It consists of 
the technical support required to eliminate programming 
errors and provide system enhancements. This function is 
usually best performed by the acti7ity which designed and 
developed the system. 

Only after reviewing Admiral Hank's article does a full 
appreciation for the scope of the development effort formu- 
late. By comparing the APADE II project and the development 
process as outlined above, the underlying reasons for 
APADE’s delay and limited success become more apparent. The 
majority of the reasons have been addressed in NAVDAC’s 
report to CNO. However, there are owe other factors which, 
in this researcher’s opinion, contributed to the limited 
success of the project. 

Although all activities within the procurement process 
are governed by the same laws and regulations, each activity 
interprets those guidelines in a slightly different manner. 
In addition, their procedures for performing the procurement 
process may vary according to prescribed local directives. 

Admiral Haak stated, ’’Special care must be taken to 
define the detailed procedural content of a proposed ADS and 
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to examine its interrelationships with the functional 
systems and standard operating procedures employed within 
the command. If the proposed procedures deviate from some 
prescribed standard system, it is prudent to propose a 
change to the standard or obtain a waiver from the appro- 
priate senior before proceeding. If the procedures cannot be 
defined in explicit, formal detail, they simply cannot be 
automated anyway' 1 [Ref. 18: p.13]. 

Functionally, the procurement process could be described 
in detail; however, the local operating procedures utilized 
by the various NFCS activities altered the process to meet 
individual command requirements. The ADS was to be used by 
all designated activities, not tailored for each individual 
command. Prior to the development of the ADS for APADE, an 
extensive planning analysis of the various procedures 
employed should have been undertaken. Additionally, the 
need to standardize the procedures among the users should 
have been evident. An initial indication of this occurred 
during FMSO's evaluation of automated systems used by MFCS 
activities. None of these systems were exportable because 
they were not comprehensive and designed in a different 
manner to suit just one activities requirements. This fact 
should have clearly indicated that there was no standard 
system among the activities. 

The environmental conditions during the development 
effort of APADE II also impacted upon the process. One 
reason previously addressed was the changing of policies 
within the Navy's ADP program. The initial development 
efforts were most likely acceptable because, similar systems 
were being developed in the same manner. However, as time 
progressed, development philosophies began to be refined and 
a new method of ADS development evolved. 
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Another reason was the sense of urgency for th a automa- 
tion of the procurement process. Faced with increasing 
procurement actions and personnel reductions combined with 
the need for improved procurement information, AP ADS 
appeared to provided the best solution to overcome these 
problems. In an effort to provide this system to the activ- 
ities, management decisions and planning were unrealisti- 
cally expedited. 

Although the APADE II project is a good example of how 
net to develop and implement an ADS, it provides valuable 
insight for managers to apply in developing and implementing 
future automated data systems. As long as the same mistakes 
are not continually repeated, progress will be made in the 
effort to automate the procurement process. 
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APPE NDI X A 

PROCUREMENT INPUT, OU TPUT , AND REPORT DOCUMENTS 

The following are examples of input documents received 
by the NSC's and NRCC's: 

1. Standard Form 129, "Bidders Mailing List Application", 

2. DD Form 633, "Contracting Pricing Proposal", 

3. DD Form 1149, "Requisition and Invoice/Shipping 
Document" , 

4. DD Form 1348, "Single Line Item Requisition Document 
(Manual) " , 

5. DD 1348M, "Single Line Item Requisition Document 
(Mechanized) ", 

6. DD Form 1348-1, " Single Line Item Release/Receipt 

Document" , 

7. DD Form 1348-6, "Non-NSN Requisition (Manual)", 

3. DD Form 1594, "Contract Completion Statement", 

9. NAVCOMPT Form 2276, "Request for Contractual 
Procurement" , 

10. NAVSUP Form 1153, "Request for Purchase Action", 

11. NAVSEA Form 4700/2, "Job Material List (JML) ", 

12. Shipment/Perf or manes Notification, 

13. Notification of Payment, 

14. Letter/Message Purchase Request, 

15. Material Request, and 

16. Automated Bid Sheets. 

The following is a list of some of the procurement 
output documents distributed by NSCs and NRCCs: 

1. Standard Form 18, " Request for Quotations", 

2. Standard Form 26, "Award/Contract", 
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3. Standard Form 30, " Amendment of 

Solicitations/Modification of Contracts", 

4. Standard Form 33, "Solicitation, Offer, and Award", 

5. Standard Form 36, "Continuation Sheet", 

6. Standard Form 98, "Notice of Intention to Make a 
Service Contract and Response to Notice", 

7. Standard Form 99 Notice of Award of Cotract", 

8. Standard Form 1034, "Public Voucher for Purchases and 
Services Other than Personal", 

9. DD Form 1155, "Order for Supplies or Services/Requast 
for Quotations" , 

10. DD Form 1384, "Transportation Control and Movement 
Document" , 

11. DD Form 1499, "Report of Individual Contract Profit 
Plan " , 

12. DD Form 1594, "Contract Completion Statement", 

13. DD Form 1501, "Abstract of 3ids", 

1 4 . DD Form 1524, "Pre-Award Survey of Offerors", 

15. DD Form 1707, "Information to Offerors of Quoters", 

16. NA7MAT Form 4380/1, "labor Surplus/Small Business Set 
Aside", 

17. Assignment to Contract Administration Activity, 

18. 3est and Final Notification, 

19. Bidder's Lists, 

20. Bid Verification, Blanket Purchase Agreement 
(BPA) /Basic Ordering Agreement (30A) , 

21. Business Clearances (Pre and Post), 

22. Buyers' Draft Sheet, 

23. Navy Chief of Information (CNINFO) New Release, 

24. Commerce Business Daily Synopsis (before and after 
award) , 

25. Contract Review Board Approval Request, 

26. Cure Notice, 
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27. D&F (Determination and Findings), 

28. Letter Contract, 

29. Non-Personal Services Questionnaire, 

30. Non-Standard Procurement Notification, 

31. Notice of Intent to Exercise Option, 

Notice of Termination, 

Notice to Unseccessful Offerors, 

RAN (Request for Authority to Negotiate), 

35. Request for Audit, 

36. Request for COT R/Orie ring Officer Assianment, 

37. Request for EIO Compliance Check, 

38. Request for Latest Collective Bargaining Agreement, 

39. Request for Non-Personal Services Statement, 

Request for Ordering Data, 
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33 

34 



40 
4 1 



Request fo SBA for Certificate of Competency, 



42. Request for Sole Source Statement, 

43. Request for Statement of Urgency, 

44. Request for Technical Evaluation Factors, 

45. Show Cause Letter, 

46. Stop Work Order, and 

47. UADPS_S? Update Transactions. 

The NSCs and NRCCs produce , among others, the following 
reDorts : 



1. DD Form 350, ’’Individual Procurement Action Report", 

2. DD Form 1057, "Monthly Procurement Summary by 
Purchasing Ofice", 

3. NAVSUP Form 80, ’’Purchase Statistics", 

4. Small and Disadvantaged Business Utilization Report, 

5. Monthly Procurement Administrative Leadtime Report, 

5. Letter Contract /Other Unpriced Order Report, 

7. Uniform Management Report, and 

8. Monthly Procurement 3acklog Report. 
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APPENDIX B 

COMMAND PLAN #338 



CO^IAND PLAN APADE 
REVISED April 1977 



1. Organizational Element : 

Deputy Commander, Procurement Management. 

2. Goal Statement : 

To provide an automated procurement management system to major 
field procurement activities. 

a • 

3. Naval Supply Systems Command Objectives Supported : 

Specific Objectives SO (Source Data Automation), 35 (Improved 
Supply Performance) , and 92 (Automation of Procurement) . 

4 . Statement of Significance: 

The APADE project will provide an automated procurement management 
system to 11 NAVSUP procurement activities and 18 other major field 
purchasing activities with capabilities for PR/requisition trackings 
automated document preparation, and management information reports. 

The system will also have source data automation capabilities to 
enable transfer of pertinent procurement data to interfacing, depen- 
dent financial and supply data systems without manual intervention. 
Overall effect will be to improve field procurement function, reduce 
cost of procurement operation, reduce procurement administrative 
leadtime, provide more responsive support to NFPS customers. 

5 . Means to Measure Progress Toward Goal Accomplishment : 

The NAVSUP Command Plan reporting system will be utilized to 
monitor accomplishment of this goal. 

6. Tasks Which Contribute Toward Goal Accomplishment : 

a. Finalize Systems Policy Concept. 

b. Develop Systems Design Specification. 

c. Identify Hardware Requirements and Software Requirements. 

d. Develop requirements documentation. 

e. Obtain Hardware requisition approval. 

f. Procure Hardware/Software. 



Enclosure (1) 



t 






g. Test and Implement at NSC Oakland. 

h. Implement at remaining NAVSUP commanded activities. 

i. Implement at non-NAVSUP commanded activities (18 sites). 

7. Description of Activity Goals : 

FMSO - Provide analysis, contracting, implementation and maintenance 
support, 

3, Availability of Authority Within Organizational Element to 
Accomplish Goal; 

. For NAVSUP commanded activities no additional authority is required. 
‘For non-NAVSUP commanded activities authorization will be coordinated 
with NAVMAT and parent SYSCGM's. 



• 9. Estimated Time for Accomplishments : 

NAVSUP commanded activities - 18 months after approval. 
Non-NAVSUP commanded activities - 36 months after approval - 

10. Relationships Between This and Other Goals Submitted by 
Organizational Elements : 

None. j 

f 

) 

11. Resources: 

/ 

a. SUP 02 - 2M/Y. 

SUP 04 - 2M/Y. 

b. FMSU'96 - 4M/Y. 
maintenance IM/Y continuing. 

c. $1.3M OPN for 11 NAVSUP activities available FY 77. 

d. $1.8M OPN for 13 non-NAVSUP CPOM 79). 

e. $50 - 75K 0§MN $ for contractor support. 



-'L 
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COMMAND PLAN: 33ft REVISED APR 1977 
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ROGKAM PLAN — NAVSUP FORM 2611 <7 66) 



COMMAND PLAN: 338 REVISED APR 1977 1978 
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•ROGRAM PLAN — NAVSUP FORM 2611 (7 66) 



COMMAND PLAN: 338 REVISED APR 1977 
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PROGRAM PLAN — NAVSUP FORM 26U (7 66) 



APPENDIX £ 

APADE II SYSTEM ? ONCTIONAL REQUI REM ENTS 
Procur ement Tra ck ing 

The APADE II system shall provide on-line request and 
retrieval functions to support the procurement tracking 
process. These functions shall provide interactive terminal 
access to the Purchase Master File disk records giving 
information regarding the general purchase request status. 

Pro curement Record/ Hist ory 

The APADE II system shall support the functions of 
procurement records and history by providing a Purchase 
Master File on disk containing a record for each active 
procurement in process. A Purchase Master File record shall 
be initiated each time the Procurement Branch begins a 
procurement activity. As the activity moves through the 
various stages of procurement/ the corresponding records of 
the Purchase Master File shall be updated via local or 
remote interactive CRT and batch modes. 

Docum ent Ge ne ration 

The document generation function shall imclude a 
combination of on-line interactive CRT data entry and 
periodic batch operations. Specific Navy and other military 
regulations shall be entered via this function and stored on 
disk by the system. This information shall then be 
available for retrieval and editing along with the entry of 
specific text for the preparation of the various formal 
procurement documents. 
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Management In form ation 

The management information function shall provide a 
combination of interactive on-line data entry and batch 
oriented operations. The procurement office management 
requires the ability to request information/data from the 
APADSII System on various aspects of the procurement office 
processing (auditing) cycle plus the ability to generate 
periodic batch reports. The reports may then be utilized by 
internal procurement office personnel and external Navy 
commands for purposes of reviewing each procurement office’s 
progress, outstanding purchase requests, situations, and 
expenditure data. 

Telec om mun icati on Interface 

The telecommunication interface function shall provide 
the ability for the APADE II System to communicate via 
common carrier (telephone facilitiesi services with external 
U.S. Navy Financial and Supply computerized Data Systems. 
This interface shall be utilized by the Navy Procurement 
Office for purposes of exchanging (input or output) APADE II 
data/information with certain other Navy facilities. 
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APPENDIX D 

APADE II IN IT I Mi TASK ORDERS TO GSA -IDSF 

Tas k One - System S pecif ic a tion s (SS) 

The System Specif ica tic n is written to provide detailed 
definition of the system functions, to provide ongoing 
analysis, and to define in detail the facilities to be 
utilized to accomplish the interfaces. All programs 
necessary are described. The SS shall be written according 

to NAVSUP PUB'S 506, 507, and 508 and as such will be based 
on the APADE II Functional Description (FD) . The SS will be 
reviewed by FMSO for consistency with the FD. The approved 
SS will be the basis for further system development. If 
modifications are found to be appropriat® to the ss, all 
such changes shall be made by the development contractor 
only on written approval by NAVSUP. 

Tas k Two - Data Base Spe ci f icat ions ( DS ) 

The DS describes the storage allocation and dara base 
organization that provides the basic design data necessary 
for construction of system files, tables, dictionaries and 
directories. The DS shall be written according to NAVSUP 
PUB'S 506, 507 and 508 and as such shall be based on the FD, 
RD, SS, and PS. The DS will be subject to FMSO approval and 
once approved all changes shall be reviewed and approved by 
FMSO. 

Tas k Three - Test Plan 

Test plans will be written for two levels of formal 
testing. The upper level of test plan shall be based on the 
FD objectives and requirements while the lower level shall 
be based on the SS and its identified requirements. Th® 
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test plan shall be reviewed and approved by FMSO. The 
Functional Test Plan on upper level test plan shall test the 
system from the user viewpoint and will demonstrate system 
inputs and outputs at the user level. The program test plan 
shall test the system from the maintainer's viewpoint and 
shall demonstrate consistency between delivered 
documentation and the system code that is used. 

Task Fou r - Program s peci fi cation (PS) 

The PS describes the program design in sufficient detail 
to permit program production by the coder. References for 
the PS are the FD and the SS. The PS shall be written 
according to NA VS UP PUB's 5 06, 507 and 508. The PS shall be 
submitted to FMSO for review of consistency with the SS and 
FD. Changes which do not effect these higher level 
documents may be made by the development contractor at his 
discretion but must be submitted for review by FMSO. 

Task Fou r - Program C od ing an d T e sting 

The individual programs identified in the PS shall be 
coded in a structured manner according to the design of the 
program specification. After successful compilation each 
shall be tested by a test designed by the coder. After 
successful testing the development contractor's quality 
assurance manager shall review the programmer's notebook, 
the code and test results to ensure that •‘■he code meets the 
PS requirements. 

Tas k Six - System I nt eg ret i o n 

The individual programs will be integrated into a unit 
and tested according to the Program Test Plan. After 
completion the software program package and test result will 
be reviewed by the development contractors quality assurance 
manager. The system operations and functions shall then be 
tested according to the Functional Fast Plan and the results 
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reported to FMSO by the development contractor's quality 
assurance manager. The Functional Test will be made with 
FMSO representation present. 

Task Seven - Acceptance Tes ting 

The software program package shall be installed at NSC 
Oakland and operated by Navy personnel for a one month 
period. The Navy shall log all software incidences during 
the period and the development contractor shall correct any 
deficiences and modify the system documentation 
correspondingly. When all deficiences are corrected an 
additional two week test shall be conducted to ensure 
correction of the 30 day test deficiences. 

Task Bigh t - User Manuals 

A complete set of user documentation for each 

implementation site (35) shall be provided by the 
contractor. This documentation will include detailed desk 
procedures for purchase personnel and an executive users 
manual for purchase management personnel. This executive 
manual will provide summary information such as reports 
available, options available, summary outline for system 
operation, etc. 

Task Nine - T rainin g 

Training for the user and for the software maintainer 
shall be performed by the development contractor. Qser 
training shall be conducted for complete operation by 
procurement buyers and clerks. Additional material will be 
presented to guide the user in obtaining * he full use of 
hardware and software maintenance support. User training 
shall be based on the User Manual and shall consist of 16 
hours of on-site instruction at NSC-Oakland. Software 
maintenance training shall consist of 32 hours of classroom 
instruction. Software maintenance training shall be based 



9d 



on the complete software program package, 
documentation (FD, SD , SS, DS, PS). 



all system 



Task Ten - Quality Assurance Pro g ram 

The development contractor shall designate a quality 
assurance manager who shall review all documentation for 
consistency and completeness. He shall be responsible for 
assuring that all documents ate consistent with the final 
product and shall review all changesto the FD, SD, SS, DS, 
and PS. He will prepare the functional and program test 
plans and shall review individual code tests prior to their 
integration into the system. He will perticipate in the 



system testing 
results. 



and shall prepare test reports on the 
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